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Abstract 


A  set  of  network  attacks  was  created  at  DRDC  Ottawa  for  the  purpose  of  testing  network 
attack  detection  and  visualisation  methods.  The  network  attack  traces  were  generated  by 
extracting  attacks  from  real-world  networks,  from  closed  networks  specifically  set  up  to  test 
attacks,  and  through  the  use  of  custom  software  written  to  simulate  attack  traffic.  In  this 
document,  the  attacks  included  in  the  data  set  are  described  in  detail  along  with  the  method 
used  to  generate  them.  The  softw  are  tools  used  in  the  creation  of  the  data  sets  arc  presented 
and  issues  involved  in  the  generation  of  the  data  arc  discussed.  The  52  attack  traces  are 
available  on  a  CD  in  a  purified  form. 


Resume 


On  a  cree  une  serie  de  simulations  d’attaques  reseau  a  RDDC,  a  Ottawa,  afin  de  mettle  a 
l’essai  les  methodes  de  detection  et  de  visualisation  des  attaques  sur  le  reseau.  On  a  genere 
les  traces  laissees  par  les  attaques  reseau  en  procedant  a  1’ extraction  des  donnees  sur  les 
attaques  dans  les  reseaux  du  monde  reel,  les  reseaux  fermes  configures  specifiquement  pour 
simuler  les  attaques  ainsi  qu’a  Taide  de  logiciels  personnalises  crees  pour  simuler  le  trafic 
reseau  lors  des  attaques.  Vous  trouverez  dans  le  present  document  la  description  detaillee 
des  attaques  definies  dans  les  ensembles  de  donnees  ainsi  que  des  methodes  utilisees  pour 
les  generer.  On  y  decrit  egalement  les  outils  logiciels  utilises  pour  creer  les  ensembles  de 
donnees  et  les  questions  concernant  la  production  des  donnees.  Les  traces  laissees  par  les 
52  attaques  sont  disponibles  sur  CD  sous  forme  epuree. 
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Executive  summary 

Background 

The  Network  Information  Operations  (NIO)  section  at  DRDC  Ottawa  has  identified  net¬ 
work  attack  detection  as  a  vital  research  area  in  the  field  of  NIO.  There  is  a  requirement  for 
further  research  in  the  area  of  Intrusion  Detection  (ID),  as  current  techniques  arc  thought 
to  be  unsatisfactory  in  some  regal'd  or  another.  Signature -based  ID  systems  are  rigid  and 
lack  the  ability  to  change  without  human  intervention,  while  anomaly  detection  techniques 
often  result  in  a  high  degree  of  false  positives  and  can  sometimes  be  re-trained. 

To  verify  their  effectiveness  and  completeness,  new  methods  for  network  intrusion  detec¬ 
tion  and  network  attack  traffic  visualisation  must  be  tested  with  actual  network  traffic.  In 
the  past  this  has  largely  been  done  with  an  arbitrary  traffic  set,  or  one  which  has  not  been 
completely  investigated.  Researchers  require  a  set  of  known,  well  documented  data  with 
which  to  test  their  algorithms.  This  is  the  purpose  of  this  body  of  work. 

Principal  Results 

Attack  traces  were  collected  in  four  categories  of  attack:  reconnaissance,  escalation,  denial 
of  service  and  covert  data  transfer.  The  primary  source  of  real  traces  was  the  Defence  Re¬ 
search  Establishment  network  (DREnet),  which  provided  a  large  amount  of  reconnaissance 
traffic.  Other  required  traces  were  either  crafted  using  custom  software  or  generated  in  a 
laboratory  environment.  One  trace  was  extracted  from  the  DEFCON  8  “Capture  the  Flag” 
contest  traffic.  In  total,  52  traces  were  collected,  along  with  one  steganography  example. 

The  IP  addresses  of  all  of  the  traces  were  altered  so  that  the  traces  would  appeal'  as  though 
they  were  extracted  from  the  same  network.  The  traces  are  presented  in  two  formats  on 
the  distribution  CD:  the  first  includes  the  trace  alone,  and  the  second  is  the  attack  traffic 
placed  in  the  middle  of  one  hour  of  ambient  traffic  collected  from  the  DREnet.  This  hour 
of  traffic  was  first  cleaned  by  removing  all  TCP  anomalies  and  removing  all  suspicious 
traffic  as  detected  by  the  Snort  IDS.  For  the  distribution  intended  for  external  parties,  the 
ambient  traffic  was  also  purified,  obfuscating  all  DREnet  IP  addresses  and  removing  all 
packet  payload. 

Significance  of  Results  and  Future  Work 

This  data  set  will  enable  the  Attack  Detection  and  Analysis  group  to  test  the  limits  of 
intrusion  detection  systems  and  to  systematically  test  new  intrusion  detection  techniques 
and  network  traffic  visualisation  techniques.  The  reference  data  set  should  be  continually 
updated  with  new  attacks.  The  capabilities  of  the  software  have  been  included  in  DRDC’s 
Network  Traffic  Analysis  Toolbox  as  powerful  packet  and  trace  manipulation  functions. 

J.  McKenna  and  J.  Treurniet;  2004;  Network  Attack  Reference  Data  Set;  DRDC  Ottawa  TM 
2004-242;  Defence  R&D  Canada  -  Ottawa. 
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Sommaire 


Contexte 

La  section  des  Operations  d'information  de  reseau  de  RDDC,  a  Ottawa,  a  defini  la  detection 
des  attaques  reseau  comme  un  secteur  de  recherche  essentiel  a  ses  operations.  II  apparait 
necessaire  d’approfondir  les  recherches  dans  le  secteur  de  la  detection  des  intrusions,  car  les 
techniques  actuelles  sont  jugees  insatisfaisantes  a  certains  egards.  Les  systemes  de  detection 
des  intrusions  qui  utilisent  l’approche  par  signature  sont  rigides  et  ne  permettent  pas  d’ap- 
porter  des  modifications  sans  intervention  humaine,  tandis  que  les  techniques  de  detection 
des  anomalies  se  traduisent  souvent  par  un  taux  eleve  de  faux  positifs  et  peuvent  parfois 
etre  perfectionnees. 

Pour  s’assurer  de  Lefficacite  et  de  l’integralite  des  nouvelles  methodes  de  detection  des 
intrusions  sur  le  reseau  et  de  visualisation  du  trafic  reseau  lors  des  attaques,  il  faut  en  faire 
l’essai  dans  le  trafic  reseau  reel.  Dans  le  passe,  les  essais  ont  ete  menes  en  grande  partie 
dans  des  ensembles  de  donnees  arbitraires  sur  le  trafic  ou  avec  des  donnees  n’ayant  pas 
fait  l’objet  d’un  examen  complet.  Or,  les  chercheurs  ont  besoin  d’utiliser  des  ensembles  de 
donnees  connues  et  bien  documentees  pour  tester  leurs  algorithmes,  et  c’est  de  cela  dont  il 
est  question  dans  les  presents  travaux. 


Resultats  principaux 

On  a  recueilli  les  traces  laissees  par  les  attaques  pour  les  quatre  categories  suivantes  :  recon¬ 
naissance,  elevation  de  privilege,  deni  de  service  et  transfert  de  donnees  secretes.  Le  reseau 
DRENnet  (Centre  de  recherches  pour  la  defense)  constituait  la  principale  source  de  traces 
reelles  et  a  fourni  une  grande  partie  des  donnees  sur  le  trafic  relatif  a  la  reconnaissance.  Les 
autres  traces  requises  ont  ete  soit  produites  a  l’aide  de  logiciels  personnalises,  soit  generees 
dans  un  environnement  d’essai  en  laboratoire.  On  a  extrait  une  trace  du  trafic  relatif  au  jeu 
“saisir  le  drapeau”  a  DEFCON  8.  Au  total,  52  traces  ont  ete  recueillies,  de  meme  qu’un 
exemple  de  steganographie. 

On  a  modifie  les  adresses  IP  de  toutes  les  traces  pour  donner  V  illusion  que  les  traces  ont 
ete  extraites  du  meme  reseau.  Les  traces  sont  presentees  en  deux  formats  sur  le  CD  de 
distribution  :  le  premier  represente  la  trace  seule,  et  le  deuxieme  represente  le  trafic  local 
tire  du  reseau  DREnet  sounds  au  trafic  de  l’attaque  pendant  une  heure.  Ce  trafic  a  d’abord 
ete  nettoye  et  depouille  de  toute  anomalie  de  type  TCP  ainsi  que  de  tout  trafic  suspect 
detecte  par  Snort  IDS.  Afin  de  permettre  la  distribution  du  CD  a  des  parties  externes,  on  a 
egalement  epure  le  trafic  local,  en  masquant  toutes  les  adresses  IP  du  reseau  DREnet  et  en 
retirant  tous  les  paquets  de  charge  utile. 


Portee  des  resultats  et  travaux  futurs 

Cet  ensemble  de  donnees  permettra  au  groupe  de  detection  et  d’ analyse  des  attaques  de 
mettre  a  l’epreuve  les  limites  des  systemes  de  detection  des  intrusions  et  de  tester  systematiquement 
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les  nouvelles  techniques  de  detection  des  intrusions  et  de  visualisation  du  trafic  reseau. 
L’ ensemble  de  donnees  de  reference  fera  l’objet  d’une  mise  a  jour  continue  et  tiendra 
compte  de  toute  nouvelle  attaque.  La  boite  a  outils  d' analyse  du  trafic  reseau  de  RDDC 
renferme  les  fonctionnalites  du  logiciel  sous  forme  de  puissantes  fonctions  de  manipulation 
des  paquets  et  des  traces. 


J.  McKenna  and  J.  Treurniet;  2004;  Network  Attack  Reference  Data  Set;  DRDC  Ottawa  TM 
2004-242;  R  &  D  pour  la  defense  Canada  -  Ottawa. 
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1  Introduction 


Network  attack  detection  and  analysis  plays  an  important  role  in  network  security.  The 
methods  currently  employed  in  Intrusion  Detection  Systems  (IDS)  arc  thought  to  be  unsat¬ 
isfactory  in  some  regard  or  another  [1,  2],  Misuse  detection  techniques,  through  systems 
that  detect  bad  network  behaviour  based  on  signatures,  lack  the  ability  to  change  without 
human  intervention  and  therefore  can  introduce  false  negatives  in  its  reports.  Anomaly 
detection  techniques,  through  systems  that  detect  bad  behaviour  based  on  profiling,  are 
widely  thought  to  be  poor  in  their  false  positive  reporting.  These  methods  also  may  allow 
re-training  by  the  skilled  attacker  to  accept  malicious  behaviour  as  normal.  Research  in  this 
area  is  essential  to  the  protection  of  our  network  infrastructure.  DRDC  Ottawa  is  currently 
investigating  new  techniques  for  attack  detection,  including  strict  anomaly  detection  and 
the  application  of  neural  network  techniques. 

New  methods  for  network  intrusion  detection  and  network  attack  traffic  visualisation  must 
be  tested  with  actual  network  traffic  to  verify  their  effectiveness  and  completeness.  In  the 
past  this  has  largely  been  done  with  an  arbitrary  traffic  set,  or  one  which  has  not  been 
completely  investigated.  This  leads  to  doubt  regarding  the  results  of  the  test.  Researchers 
require  a  set  of  known,  well  documented  data  with  which  to  test  their  algorithms.  This  is 
the  purpose  of  this  body  of  work. 

MIT’s  DARPA  Intrusion  Detection  Evaluation  data  [3]  is  a  well-known  existing  data  set, 
which  includes  traffic  with  documented  attacks  on  a  small  simulated  network.  In  these 
traces,  the  logs  arc  collected  daily  and  the  attacks  arc  interspersed  at  random  times.  We  aim 
to  create  traces  that  last  for  one  hour  and  contain  just  one  attack,  using  a  network  that  is 
substantially  larger. 

Note  that  the  definition  of  attack  will  vary  from  person  to  person.  In  this  document,  the 
term  is  used  to  describe  any  suspicious  activity  that  occurs  on  the  network,  including  scans. 

2  Types  of  Attacks 


Attacks  can  be  categorized  in  many  ways.  Dain  and  Cunningham  [4]  separate  attacks  into  5 
broad  categories:  network  discovery,  host  discovery,  escalation,  denial  of  service  and  covert 
data  transfer.  We  use  this  scheme,  combining  network  and  host  discovery  into  one  category, 
labelled  reconnaissance,  due  to  the  overlap  between  the  two  categories.1  This  section  gives 
a  brief  description  of  the  kinds  of  attacks  that  arc  included  in  the  reference  data  set. 

2.1  Reconnaissance 

We  define  reconnaissance  as  the  attempt  to  gain  information  about  hosts  on  a  network,  the 
services  they  offer,  or  the  versions  of  software  components  installed.  This  is  generally  the 

'Note  that  there  is  some  overlap  among  the  other  categories  as  well.  An  improved  taxonomy  is  under 
investigation  and  is  beyond  the  scope  of  this  report. 
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first  stage  in  an  attack,  which  helps  the  attacker  find  potential  targets,  or  gain  information 
about  a  specific  target. 


2.1.1  Scans 

We  define  a  network  scan  as  a  set  of  related  probes  directed  at  one  or  more  hosts  on  a 
network.  Typically,  a  network  scan  is  used  to  determine  the  existence  of  network  nodes  or 
devices,  and  possibly  the  services  they  offer.  When  the  attacker  attempts  to  access  system 
services  in  order  to  determine  which  arc  available,  the  scan  is  called  a  “portscan”. 

Network  scans  can  be  classified  as  having  “horizontal”,  “vertical”,  “block”  or  “strobe” 
footprints  [5,  6].  To  visualise  the  origin  of  these  terms,  consider  a  Cartesian  plot  with  IP 
address  on  the  x-axis  and  port  on  the  y-axis.  If  a  network  scan  probes  a  contiguous  range 
of  IP  addresses  for  a  single  port  of  interest,  a  plot  of  (IP  address,port)  would  appeal-  as  a 
horizontal  line.  A  network  scan  of  probes  directed  to  one  host  and  a  contiguous  range  of 
ports  would  appear  as  a  vertical  line.  Scans  of  IP  address  ranges  for  ranges  of  ports  would 
appeal-  as  blocks.  Probes  directed  to  a  non-contiguous  set  of  ports  on  one  or  more  hosts 
would  constitute  a  strobe  scan. 

The  three  most  prevalent  protocols  used  in  scanning  are  TCP,  UDP  and  ICMP  [7].  Because 
TCP  and  UDP  work  at  the  transport  layer  of  the  TCP/IP  protocol  suite  [8] ,  they  use  ports 
to  establish  connections.  A  probe  for  a  service  on  a  particular  port  can  be  performed  using 
the  TCP  protocol:  a  TCP  packet  with  the  SYN  flag  set  is  a  connection  request;  once  estab¬ 
lished,  the  connection  can  be  closed  gracefully  with  a  TCP  FIN  packet  or  torn  down  with 
transmission  of  a  TCP  RST  packet.  A  TCP  packet  with  disallowed  flag  combinations,  e.g. 
with  both  SYN  and  FIN  flags  set,  can  also  be  used  to  elicit  a  response  from  hosts  on  the 
network.  Acceptable  flag  combinations  can  elicit  a  response  when  directed  to  a  host  that 
has  not  initiated  a  connection.  At  one  time  these  were  considered  stealth  techniques  [9], 
but  they  are  now  easily  detected.  Inverse  mapping  can  be  accomplished  by  using  TCP  RST 
packets:  if  a  host  does  not  exist,  some  routers  will  happily  respond  to  a  TCP  RST  with  an 
ICMP  host  unreachable  message  [9]. 

A  probe  for  a  service  on  a  particular  port  may  also  be  carried  out  using  the  UDP  protocol. 
When  an  empty  UDP  datagram  is  sent  to  an  open  port,  the  host  either  responds  with  an 
error  message  or  makes  no  response.  If  a  UDP  packet  is  sent  to  a  closed  port  on  a  host,  the 
host  may  respond  with  an  ICMP  port  unreachable  message.  This  allows  an  attacker  to  test 
for  the  presence  of  filtering. 

The  ICMP  protocol,  which  operates  at  the  network  layer  of  the  TCP/IP  protocol  suite, 
provides  a  means  of  testing  for  the  existence  of  hosts  on  a  network.  If  a  host  is  up  and  there 
is  no  filtering  for  ICMP,  an  ICMP  echo  request  (commonly  termed  a  “ping”)  will  elicit  an 
echo  reply.  Note  that  probes  for  a  range  of  IP  addresses  using  a  protocol  that  does  not  use 
ports,  such  as  ICMP,  would  be  classified  as  a  horizontal  scan. 
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2.1.2  Traceroute 


Traceroute  is  a  tool  used  to  map  the  route  between  one  host  and  another,  and  may  be  used 
by  an  attacker  to  provide  a  map  of  the  network  of  interest.  It  works  on  the  premise  that 
the  time-to-live  (TTL)  field  in  the  IP  header  is  decremented  at  each  router  on  it’s  path. 
When  the  TTL  of  a  packet  reaches  0,  an  ICMP  time  exceeded  message  is  sent  back  to  the 
originating  host. 

The  process  of  tracing  the  route  between  two  hosts  proceeds  as  follows.  A  UDP  or  ICMP 
echo  request  packet  is  sent  out,  with  an  initial  TTL  value  of  1.  When  it  reaches  the  first 
router,  an  ICMP  time  exceeded  message  is  returned.  Packets  are  sent  in  this  fashion,  with 
the  TTL  value  of  each  new  packet  incremented  by  1,  until  the  target  host  is  reached  and  a 
complete  map  of  the  route  between  the  two  hosts  is  created. 

2.1.3  Operating  System  Identification 

Identification  of  an  Operating  System  (OS)  from  its  response  to  stimuli  is  called  finger¬ 
printing.  Most  OSs,  and  some  OS  versions,  can  be  differentiated  by  these  responses,  based 
on  the  behaviour  of  their  TCP  or  ICMP  implementation.  Common  OS  fingerprinting  tools 
include  QueSO  [10]  (literally  translates  to  “what  OS”)  and  nmap  [11],  however  there  are  a 
number  of  additional  tools  available  for  download. 

2.1 .4  Vulnerability  Assessment  Tools 

Vulnerability  Assessment  (VA)  tools  arc  meant  to  be  used  by  network  security  adminis¬ 
trators  to  assess  the  security  of  their  networks,  but  may  be  used  by  attackers  to  identify 
vulnerable  hosts.  The  CyberCop  tool  [12]  has  been  used  for  years  and  is  still  effective  in 
identifying  vulnerabilities  in  a  system. 

2.1.5  Stealth  Methods 

Stealth  techniques  arc  often  employed  to  prevent  detection  of  scans  by  IDS.  Methods  of 
avoiding  detection  include  randomization  of  IP  sequences,  slowing  the  rate  of  probing,  and 
introducing  random  time  intervals  between  probes.  These  methods  decrease  the  likelihood 
that  an  IDS  will  correlate  the  individual  probes.  An  attacker  may  also  randomize  non- 
essential  fields  to  avoid  the  presence  of  a  “tool  signature”  [5]. 

In  the  “needle  in  a  haystack”  technique,  an  attacker  launches  a  very  noisy  (fast  and  vo¬ 
luminous)  scan  from  one  host  under  its  control,  and  during  this  scan  sends  a  few  probes 
from  another  host  to  the  target.  The  attacker’s  actual  target  is  obscured  by  the  noise  and 
the  attack  may  thereby  go  unrecognized.  Distributed  or  coordinated  scanning  [13],  similar 
to  distributed  denial  of  service,  uses  a  number  of  compromised  hosts,  each  collaborating  to 
scan  different  areas  of  a  network  or  host.  The  identity  of  the  attacker  is  hidden. 

Stealth  methods  can  be  applied  to  any  of  the  reconnaissance  techniques  described  here. 
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2.2  Escalation 


The  escalation  category  [4]  consists  of  attacks  that  attempt  to  gain  access  to  the  target. 
Examples  of  escalation  attempts  include  buffer  overflow  attacks  and  password  cracking. 

2.2.1  Buffer  Overflow 

Buffer  overflow  attacks  can  allow  an  attacker  to  run  arbitrary  code  on  a  host.  This  is  ac¬ 
complished  by  sending  more  data  to  an  application  than  the  buffer  was  designed  to  handle. 
The  extra  data  overflows  into  an  adjacent  buffer,  which  may  result  in  the  execution  of  code. 

2.2.2  Password  Cracking 

Password  cracking  can  be  done  using  online  methods  or  offline  methods.  Online  methods 
use  a  list  of  common  passwords  to  try  to  guess  the  password.  Repeated  connection  attempts 
arc  made  using  the  passwords  in  the  dictionary,  which  makes  this  method  very  noisy  and  not 
always  successful.  Software  such  as  John  the  Ripper  [14]  is  an  online  password  guessing 
package  that  is  intended  for  local  use  by  security  administrators,  to  disallow  the  use  of 
easily-guessed  passwords.  In  an  attack  using  offline  methods,  a  copy  of  the  /etc/passwd 
and  /etc/shadow  files  are  retrieved  and  attempts  to  guess  the  passwords  arc  made  locally. 
The  Brutus  [15]  tool  combines  both  of  the  above  methods  of  password  cracking,  and  is  also 
intended  for  use  by  security  administrators. 


2.3  Denial  of  Service 

Denial  of  Service  (DoS)  attacks  compromise  the  availability  of  a  host.  This  can  be  accom¬ 
plished  by  exploiting  a  vulnerability  (commonly  with  a  single  packet),  effectively  disabling 
a  service  or  operating  system,  or  by  overflowing  the  host’s  capacity  for  traffic  with  an  un¬ 
manageable  amount  of  data  (a  “packet  flood”). 

2.3.1  Vulnerability  DoS 

The  Land  attack  [9]  (named  after  an  exploit  program,  land .  c)  is  an  example  of  a  vulnera¬ 
bility  DoS  attack.  The  attack  forges  the  source  IP  to  be  identical  to  the  destination  IP  and 
thus  creates  a  loop  which  can  crash  vulnerable  operating  systems.  Although  most  mod¬ 
ern  operating  systems  arc  not  vulnerable  to  this  exploit,  there  are  still  several  unpatched 
versions  out  there  (notably  Windows  ’95). 

The  Teardrop  attack  [9]  has  an  effect  similar  to  the  Land  attack.  A  fragmented  packet  is 
received  and  its  data  is  written  into  memory.  A  second  packet  containing  an  incorrect  offset 
that  overlaps  this  memory  is  received,  resulting  a  system  crash.  This  has  been  patched 
on  most  operating  systems,  but  some  vulnerable  hosts  still  remain  in  use  (again,  notably 
Windows  ’95). 
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2.3.2  Multipacket  DoS 


DoS  can  also  be  achieved  through  packet  flooding.  This  can  be  done  by  overwhelming 
either  the  link  to  the  host,  or  the  host  itself. 

The  Smurf  attack  [9]  uses  IP  broadcast  addresses  to  magnify  traffic.  It  sends  an  ICMP 
echo  request  to  several  network  broadcast  addresses,  with  a  return  IP  address  spoofed  to 
that  of  the  victim.  The  resultant  flood  of  ping  responses  overwhelms  the  link  to  the  victim, 
resulting  in  a  denial  of  service  by  packet  flood.  The  ICMP  protocol  has  been  amended  to 
specify  that  routers/gateways  may  include  an  option  to  drop  traffic  directed  at  IP  broadcast 
addresses  [16],  however  this  option  is  not  always  implemented  by  networks  [17]. 

Many  older  operating  systems  are  vulnerable  to  a  TCP  SYN flood  attack  [9].  In  this  attack, 
TCP  connection  requests  are  received  by  the  victim,  and  TCP  puts  each  in  queue  for  a 
response.  While  the  maximum  number  of  uncompleted  (half-open)  connections  that  may 
exist  is  exceeded,  the  victim  is  rendered  unable  to  establish  legitimate  connections. 

In  the  Distributed  Denial  of  Service  (DDoS)  attack  [18],  an  attacker  compromises  a  host 
and  installs  a  DDoS  “master”  program.  From  there,  “slave”  programs  are  installed  on 
several,  sometimes  thousands,  of  compromised  hosts.  At  the  time  of  attack,  the  master 
simultaneously  orders  the  slaves  to  begin  a  packet-flood  DoS  attack  on  the  same  victim. 

Note  that  backscatter  effects  of  multipacket  TCP  DoS  can  be  mistaken  for  a  reset  scan.  The 
victim  of  the  DoS  will  send  TCP  reset  packets  to  the  originating  IP  addresses.  If  these 
addresses  were  spoofed  to  appeal-  to  be  of  the  same  address  space,  the  activity  will  take  on 
the  appearance  of  a  fast  reset  scan. 

2.4  Covert  Data  Transfer 

Covert  data  transfer  includes  methods  of  relaying  information  in  a  manner  that  is  difficult 
to  detect.  Both  tunnelling  and  information  hiding  are  included  in  this  category. 

2.4.1  Tunnels 

The  ICMP  protocol  can  be  used  to  transfer  data.  The  data  is  written  in  the  content  of 
ICMP  echo  request  and  reply  packets,  and  may  be  encrypted.  The  Loki  [19]  tool  is  one 
well-known  example. 

2.4.2  Information  Hiding 

The  information  hiding  category  includes  methods  of  hiding  information  in  undetectable 
ways.  For  example,  steganography  transfers  information  through  subtle  changes  in  elec¬ 
tronic  pictures. 

The  header  fields  in  TCP  packets  can  be  used  to  carry  data  [20].  The  IP  ID  and  TCP 
sequence  number  fields  can  carry  ASCII  character  values.  The  TCP  acknowledgement 
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number  can  also  be  used  if  a  packet  carrying  information  in  it’s  sequence  number  is  bounced 
to  the  forged  IP  of  the  true  destination  host. 


3  Generation  of  Reference  Attack  Data 


Traffic  collected  from  the  Defence  Research  Establishment  network  (DREnet)  in  August 
2000,  April  2001  and  December  2002  provided  a  good  source  of  attempted  reconnaissance 
traces,  but  was  lacking  in  variety.  The  DEFCON  [21]  annual  security  conference,  which 
features  a  “Capture  the  Flag”  contest  in  which  participant  groups  attempt  to  secure  their 
own  host  while  attacking  others  on  a  local  network,  was  expected  to  be  a  plentiful  source  of 
attack  traces.  Unfortunately,  the  data  suffered  badly  from  dropped  packets  and  hence  was  a 
viable  source  for  only  one  attack  trace.  The  reference  data  set  was  completed  by  generating 
the  necessary  attacks  either  by  using  published  exploits  on  a  closed  network  or  by  crafting 
the  attack  trace  using  custom-built  tools. 

The  reference  data  set  is  stored  as  a  series  of  pcap  format  [22]  hies,  which  is  generally 
accepted  to  be  the  standard  format  for  archived  traffic.  The  corresponding  tepdump  tool 
creates  and  reads  pcap  hies  from  network  traffic.  Other  popular  tools  in  the  intrusion  detec¬ 
tion  community  support  the  pcap  hie  format,  including  Ethereal  [23],  which  may  be  used 
to  translate  pcap  hies  to  other  formats. 

The  data  set  contains  two  versions  of  each  attack:  one  version  contains  only  the  packets 
involved  in  the  attack,  and  the  other  contains  the  attack  packets  merged  with  standard  set  of 
what  we  will  call  “normal”  traffic,  to  be  discussed  further  in  Section  3.6. 

To  ensure  consistency,  all  traces  were  altered  to  appear-  as  if  they  had  been  sniffed  on  the 
same  network.  Three  class  B  address  ranges  were  required  to  accommodate  the  DREnet 
traces.  The  IP  addresses  of  ah  target  hosts  were  modified  to  have  IP  addresses  in  the  range 
172.16.0.0/16,  172.17.0.0/16  or  172.18.0.0/16.  In  closed  network,  DEFCON  and  crafted 
traces,  further  manipulation  was  necessary  to  create  realistic  traces.  The  Time-to-live  (TTL) 
helds  of  the  original  attack  packets  were  reduced  to  imply  a  greater  number  of  hops  between 
hosts.  “Jitter”,  the  variation  in  packet  arrival  time  due  to  network  delays,  was  also  intro¬ 
duced.  In  crafted  and  closed  network  traces  involving  multiple  packets,  packet  dropping 
was  introduced  at  a  rate  of  0.5%-l%  [24],  Such  manipulation  was  performed  using  custom 
tools,  described  in  Section  3.1.  Note  that  after  alteration  of  a  packet,  the  IP  and  TCP/UDP 
checksums  were  recalculated  as  required. 

3.1  Utilities 

There  are  numerous  tools  [22,  25]  available  for  analyzing  or  displaying  data  in  pcap  hies. 
While  tools  exist  to  perform  simple  manipulations  of  pcap  hies,  such  as  dividing  or  con¬ 
catenating  traces  [26]  and  purifying  traces  through  modifying  IP  address  and  removing 
content  [27],  there  is  a  shortage  of  tools  capable  of  performing  complex  manipulations  of 
them,  such  as  modification  of  header  helds  and  timestamps,  and  the  merging  of  interleaved 
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traffic  data. 


A  library  of  shared  functions,  called  TCPLib,  was  written  to  provide  an  interface  to  the 
packets  in  a  pcap  tile.  TCPLib  does  not  rely  on  libpeap  (Unix)  or  WinPcap  (Windows)  for 
effective  operation.  A  series  of  tools  collectively  dubbed  TCPUtils  was  created  to  allow  for 
the  manipulation  and  examination  of  pcap  tiles.  These  tools  arc  listed  in  Table  1. 


Table  1:  The  tools  created  for  manipulation  and  analysis  of  pcap  files.  The  tools  are 
described  in  more  detail  in  Appendix  A. 


Tool  name 

tcpiptranslate 

tcpttltranslate 

teptimeshift 

tepmerge 

tep jitter 


tcptimestretch 

tcptrunc 


teprate 

tcpcontent 


Usage 

Used  to  replace  instances  of  one  IP  address  with  another. 

Alters  the  IP  TTL  field  in  each  IP  packet  by  a  specified  amount. 
Alters  each  packet  time  stamp  by  a  specified  amount,  allowing  a 
trace  to  appeal-  as  if  it  took  place  at  a  different  time. 

Merges  two  or  more  pcap  tiles  which  may  have  interleaved  time 
stamps. 

Adds  realism  to  traces  by  altering  spacing  between  timestamps  up 
to  a  specified  percentage,  or  by  dropping  a  specified  percentage  of 
packets. 

Expands  or  compresses  gaps  in  time  between  packets. 

Truncates  packet  captured  data.  This  is  useful  when  merging 
several  traces,  each  of  which  may  have  different  packet  capture 
lengths. 

Creates  a  tab-delimited  table  of  packet  rates,  in  bytes  per  second. 
Displays  packet  payloads  in  ASCII. 


3.2  DREnet  Traffic 

The  Snort  IDS  [25]  was  used  to  analyze  data  captured  on  the  DREnet.  Snort  is  a  signature- 
based  IDS,  based  on  a  set  of  rules  to  identify  known  attacks.  The  default  set  of  rules  shipped 
with  Snort  2.0  was  used,  as  well  as  an  updated  list  of  rules  for  current  attacks  [28].  Alerts 
generated  by  Snort  were  manually  investigated.  When  an  attack  was  identified  in  the  traffic, 
tepdump  was  used  to  isolate  the  packets  involved  in  the  attack. 


3.3  DEFCON  Traffic 

Exploits  were  identified  within  traces  from  the  Capture  the  Flag  contest  at  DEFCON  8  [29]. 
Since  the  DEFCON  8  data  suffered  badly  from  dropped  packets,  it  was  decided  that  the 
focus  for  this  data  would  be  to  find  a  buffer  overflow  attack  for  which  the  trace  was  intact. 
The  Snort  IDS  was  used  to  identify  such  attacks  and  the  data  was  searched  for  a  complete 
trace.  When  such  an  attack  was  identified  in  the  traffic,  tepdump  was  used  to  isolate  the 
attack  trace.  IP  addresses  and  TTL  values  were  modified  in  the  trace  using  TCPUtils,  so 
that  the  trace  was  consistent  with  the  other  traces  in  the  data  set. 
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3.4  Closed  Network  Traffic 


Tools  to  launch  the  some  of  the  exploits  used  in  the  generation  of  attack  traffic  on  a  closed 
network  were  obtained  from  the  Internet.  The  attacks  were  launched  on  a  test  network 
consisting  of  three  machines,  two  Linux  and  one  Windows,  and  the  traffic  was  captured 
regardless  of  the  success  of  the  attack.  IP  addresses  and  TTL  values  were  modified  in  the 
trace,  and  jitter  and  packet  loss  were  introduced  using  TCPUtils. 


3.5  Crafted  Traffic 

In  some  cases,  especially  those  involving  distributed  attacks,  simulating  an  attack  with  a 
small  test  network  was  not  feasible.  As  a  result,  programs  were  written  to  generate  pcap 
format  files  containing  hypothetical  traces  for  these  types  of  attacks.  The  TCPlib  library  of 
functions  was  used  to  create  the  files.  Using  TCPUtils,  the  traces  were  crafted  to  use  consis¬ 
tent  IP  addresses  and  realistic  TTLs.  Random  packet  dropping  and  time  stamp  fluctuations 
were  also  introduced. 

3.6  Merging  Isolated  Traces  with  Clean  Data 

To  ensure  only  one  attack  in  each  traffic  trace,  each  isolated  attack  trace,  regardless  of  its 
source,  was  merged  with  a  one  hour  data  set  of  ambient  traffic  representative  of  “normal” 
network  activity. 

In  an  attempt  to  create  a  clean  data  set,  a  strict  anomaly  detection  algorithm  [30]  was  ap¬ 
plied  to  the  TCP  traffic  in  one  hour  of  DREnet  traffic.  This  algorithm  detects  illegal  flag 
sequences  and  state  transitions,  and  is  successful  in  detecting  scanning  activity  and  other 
unusual  behaviour.  All  anomalous  TCP  activity  was  removed  from  the  traffic  using  a  sim¬ 
ple  tcpdump  filter.  The  resulting  traffic  was  passed  through  the  Snort  IDS  to  verify  clean 
content,  and  all  suspicious  traffic  was  again  removed  via  a  tcpdump  filter.  At  this  stage, 
the  traffic  is  presumed  to  be  “clean”  (free  of  attacks)  to  the  best  of  our  knowledge.  Us¬ 
ing  TCPUtils ,  the  IP  addresses  of  this  traffic  were  translated  to  reflect  the  chosen  class  B 
address  ranges  172.16.0.0/16,  172.17.0.0/16  or  172.18.0.0/16.  The  resulting  data  set  is  ap¬ 
propriate  for  internal  use,  however  for  a  releasable  distribution  a  second  clean  data  set  was 
generated  where  the  class  B  addresses  were  obfuscated  and  the  content  removed  from  most 
packets  using  TCPurify  [27],  The  clean  traffic  is  included  in  the  data  set  as  a  baseline  for 
“normal”  activity. 

Attacks  that  were  less  than  one  hour  in  length  were  merged  with  the  clean  traffic,  shifted 
to  approximately  the  half-hour  mark.  Attacks  that  ran  longer  than  one  hour  were  truncated 
in  the  merged  version.  An  1-hour  window  of  data  was  selected  in  the  attack  traffic.  For 
most  files,  this  hour  begins  at  15000s  into  the  attack  trace  and  ends  at  18600s  into  the  attack 
trace.  This  hour  was  merged  with  the  clean  traffic.  The  tcptimeshift  and  tcpmerge 
utilities  were  used  to  merge  each  isolated  attack  with  the  clean  traffic,  with  special  attention 
paid  to  the  packet  capture  length  of  the  attack  traffic. 
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4  Attacks  Included  in  the  Data  Set 


This  section  contains  a  description  of  each  of  the  recorded  attacks  in  the  data  set.  The 
section  is  partitioned  into  the  categories  as  they  were  presented  in  Section  2.  When  an 
attack  type  was  not  found  in  the  data  collected  from  the  DREnet,  it  was  generated  on  a 
closed  network  or  crafted  (excluding  the  buffer  overflow  that  was  obtained  from  DEFCON). 


4.1  Reconnaissance 

Recall  that  reconnaissance  includes  scans,  OS  fingerprinting,  traceroute,  the  use  of  vulner¬ 
ability  assessment  tools,  and  stealth  activity.  We  include  a  section  for  traffic  that  may  be 
interpreted  as  a  scan  but  may  also  be  a  false  positive,  observed  as  a  backscatter  effect. 

This  section  is  organized  as  follows: 

•  Scans: 

-  Fast  horizontal  scans 

-  Fast  strobe  scan 

-  Fast  vertical  scans 

-  Fast  block  scans 

•  Stealth  activity: 

-  Slow  horizontal  scans 

-  Slow  strobe  scans 

-  Slow  vertical  scans 

-  Needle  in  a  haystack 

-  Coordinated  scans 

•  Traceroute 

•  OS  identification 

•  Vulnerability  assessment  tools 

•  Possible  false  positives 

Figures  arc  included  for  some  of  the  scans  to  illustrate  interesting  characteristics  of  the 
trace.  The  plot  is  a  simple  diagram  of  IP  address  versus  time.  The  x-axis  is  time  and  the 
set  of  all  unique  IP  addresses  that  were  involved  in  the  trace  arc  equally  spaced  along  the 
y-axis.  Two  points  arc  rendered  for  each  packet  in  the  trace:  one  for  the  source  IP  address 
of  the  packet  and  one  for  the  destination  IP  address. 
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4.1.1  Scans 


Almost  all  scans  located  in  the  DREnet  traffic  were  of  the  “horizontal”  type,  where  a  range 
of  IP  addresses  is  scanned  for  a  single  port.  The  “vertical”  scan,  where  a  single  host  is 
probed  for  a  range  of  ports,  had  to  be  generated  in  the  lab  on  a  closed  network.  The  “block” 
scan,  which  combines  both  horizontal  and  vertical  scans,  had  to  be  crafted. 

4.1 .1.1  Fast  Horizontal  Scans 

Filename:  scan_HJCMPJast_seq.tcp 

Source:  DREnet,  8  December  2002 

Duration:  4h  27m  11.7s 

Description:  A  fast  semi-sequential  ICMP  scan  of  15663  hosts  on  a  class  B  network.  The 
31275  packet  scan  is  bursty:  an  echo  request  is  sent  to  a  group  of  5-10  hosts, 
and  re-tried  about  2  seconds  later.  The  process  repeats  every  2  seconds.  Fig¬ 
ure  1  shows  the  pattern.  There  is  a  74  minute  break  about  2/3  of  the  way 
through  the  scan. 


Trace  info:  31275  packets,  15664  IP  addresses 


Figure  1:  Echo  request  scan.  The  inset  shows  the  pattern  of  packet  arrival  with  time. 


Filename:  scan_H_UDPJast_ran.tcp 

Source:  DREnet,  8  December  2002 

Duration:  10m 
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Description:  About  35  NetBIOS  queries  per  second  on  port  137,  from  185  unique  sources 
probe  19669  unique  destinations  on  3  class  B  networks.  21227  packets  are 
sent  in  total,  however  the  destination  hosts  consist  of  489  ranges  of  IP  ad¬ 
dresses  (Figure  2).  The  captured  activity  occurs  over  a  10  minute  period,  but 
is  representative  of  the  day.  This  type  of  activity  may  indicate  worm  propa¬ 
gation  through  Windows  shares. 
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172  18  33  239 

172.  17.180.201 
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Tima  (sac)  from  start  time 

Figure  2:  A  scan  for  Windows  shares  on  port  137  (NetBIOS). 

scanJrLUDP  Jast_seq.tcp 
DREnet,  29  April  2001 
5h  44m  47.4s 

A  class  B  network  is  scanned  sequentially  for  ports  407/UDP  and  1419/UDP. 
65493  unique  destination  hosts  are  scanned,  covering  almost  all  of  the  class  B 
address  space.  The  packets  arrive  at  an  average  rate  of  6.33  packets/second. 
The  source  port  is  constant  for  all  probes. 

scan_H_TCP_fast_TCPopts.tcp 
DREnet,  29  April  2001 
28m  59.2s 

A  host  makes  39343  TCP  SYN  connection  attempts  to  port  53  on  24017 
unique  destination  IP  addresses  at  a  rate  of  22.6  packets/second.  The  scan 


Filename: 

Source: 

Duration: 

Description: 


Filename: 

Source: 

Duration: 

Description: 


Trace  info:  21127  packets,  19864  IP  addresses 
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is  not  quite  sequential,  but  also  not  quite  random.  Overall,  the  scan  moves 
in  the  direction  of  increasing  IP  address,  however  there  is  some  backtracking 
and  some  IP  addresses  are  skipped.  The  inset  of  Figure  3  shows  the  pattern. 
The  unusual  feature  of  this  scan  is  that  TCP  options  are  used. 


Traci  info:  33343  packets,  24018  IP  addrassns 


Figure  3:  Fast  horizontal  scan  with  backtracking. 


Filename:  scan_FLTCP_fast_seq_skippy.tcp 

Source:  DREnet,  8  December  2002 

Duration:  18h7m9.8s 

Description:  TCP  SYN  connection  attempts  to  port  80.  The  IP  addresses  are  generally  in¬ 
creasing,  but  there  are  gaps  in  the  class  B  address  space  that  is  being  scanned, 
several  of  them  being  quite  large  gaps.  There  are  247958  packets  in  the  trace, 
but  just  27615  unique  destination  IP  addresses.  Each  IP  address  is  retried 
9  times.  The  average  rate  of  packet  arrival  is  3.80  packets  per  second.  See 
Figure  4. 


scan_H_TCP_fast_seq_classC.tcp 
DREnet,  8  December  2002 
2.1s 
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Source: 

Duration: 
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Trace  info:  247958  packets,  27616  IP  addresses 


Figure  4:  Fast  horizontal  scan  with  gaps.  The  inset  shows  the  pattern  of  TCP  retries. 

Description:  TCP  SYN  scan  of  an  address  space  corresponding  to  a  class  C  network  (254 
hosts)  for  a  known  trojan  port.  The  packets  arrive  at  an  average  rate  of  120 
packets/second,  and  there  are  gaps  in  the  timing,  as  seen  in  Figure  5. 


Filename: 

Source: 

Duration: 

Description: 


scan  _H_TCP_fast_seq_3classB.tcp 
DREnet,  8  December  2002 
4h  19m  40.1s 

TCP  SYN  scan  of  three  class  B  networks  for  one  port  (1433/sql).  Although 
the  scan  appears  to  be  sequential  in  the  large-scale  view,  a  close-up  shows 
repetition  (Figure  6).  The  trace  contains  344405  packets,  30  of  which  are 
responses  from  internal  hosts,  at  an  average  rate  of  22.11  packets/second. 
There  are  195480  unique  destination  IP  addresses. 


Filename: 

Source: 

Duration: 

Description: 


scan_H_TCP_fast_seq_synfin.tcp 
DREnet,  17  August  2000 
43.7s 

TCP  S YN/FIN  scan  of  three  class  B  networks  to  TCP  destination  port  111 
(sunrpc).  The  source  port  is  also  111.  Although  sequential  overall,  investi¬ 
gation  shows  some  variation  in  the  order  of  arrival,  mainly  for  the  first  100 
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Trace  info:  254  packets,  255  IP  addresses 


Figure  5:  Fast  small  network  scan. 


Trace  info:  344406  packets,  195481  IP  addresses 


Figure  6:  Fast  scan  of  3  class  B  networks.  The  inset  shows  the  repetition  of  attempts. 
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packets.  The  trace  contains  19721  packets  targeting  19721  unique  destination 
IP  addresses,  arriving  at  an  average  rate  of  45 1 .4  packets  per  second.  There 
is,  however,  a  pause  in  the  scan  lasting  17.2  seconds. 


4.1 .1 .2  Fast  Strobe  Scan 


Filename: 

Source: 

Duration: 

Description: 


scan_S  _TCPJast_ran.tcp 
DREnet,  29  April  2001 
lm  23.0s 

Fast  TCP  S YN  connection  attempts  to  2 1  different  ports  on  one  host  (often 
several  times  to  each  port),  12  of  which  arc  well-known  back  doors.  The 
pattern  is  repeated  on  a  different  host  35  minutes  later.  The  total  duration  of 
the  trace  including  the  scan  of  the  second  host  is  38m  13.4s. 


4.1 .1 .3  Fast  Vertical  Scans 

The  following  portscans  were  crafted  using  simPortScan .  cc  (Appendix  B.2). 


Filename:  scan_V_TCP_fast_seq_small.tcp 

Source:  Crafted  (simPortScan.cc) 

Duration:  51.1s 

Description:  A  fast,  ordered  scan  of  ports  1-1024.  The  probes  arc  sequential  at  a  rate  of  20 
packets  per  second  with  3%  jitter,  or  having  a  delay  between  packets  in  the 
interval  [0.0485s,  0.0515s], 


Filename:  scan  V  TCP  fast  ran  small. tep 

Source:  Crafted  (simPortScan.cc) 

Duration:  51.1s 

Description:  A  fast  scan  of  ports  1-1024  in  random  order.  The  probes  arc  randomized  at 
a  rate  of  20  packets  per  second  with  3%  jitter,  or  having  a  delay  between 
packets  in  the  interval  [0.0485s,  0.0515s]. 


Filename:  scan  V  TCP  fast  seq  largc.tcp 

Source:  Crafted  (simPortScan.cc) 

Duration:  54m  36.5s 

Description:  A  fast,  ordered  scan  of  ports  1-65535.  The  probes  arc  sequential  at  a  rate  of 
20  packets  per  second  with  3%  jitter,  or  having  a  delay  between  packets  in 
the  interval  [0.0485s,  0.0515s], 


Filename:  sc  an  _  V  _T  CP_fast_ran  4  arge .  tc  p 

Source:  Crafted  (simPortScan.cc) 

Duration:  54m  36.7s 
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Description:  A  fast  scan  of  ports  1-65535  in  random  order.  The  probes  are  randomized 
at  a  rate  of  20  packets  per  second  with  3%  jitter,  or  having  a  delay  between 
packets  in  the  interval  [0.0485s,  0.0515s]. 

4.1 .1 .4  Fast  Block  Scans 

The  block  scans  contain  as  many  packets  as  can  be  theoretically  fit  on  a  295kbps  line, 
approximately  700  packets  per  second.  The  traces  show  only  one  hour  of  the  block  scan, 
where  in  reality  they  would  span  multiple  hours. 

Filename:  scan_B_UDPTast_seq_small.tcp 

Source:  Crafted  (simBlockScanNormal.pl) 

Description:  A  block  scan,  sequential  in  both  IP  address  and  port.  Ports  1-1024  arc  probed 
for  as  many  IP  addresses  as  can  be  fit  into  the  hour.  No  jitter  was  introduced. 

Filename:  scan_B_TCPJast_seqdarge.tcp 

Source:  Crafted  (simBlockScanNormal.pl) 

Description :  A  block  scan,  sequential  in  both  IP  address  and  port.  Ports  1-65535  arc  probed 
for  as  many  IP  addresses  as  can  be  fit  into  the  hour.  No  jitter  was  introduced. 

Filename:  scan  B  TCP  fast  ran  large. tcp 

Source:  Crafted  (simBlockScanRandom.pl) 

Description:  A  block  scan,  randomized  in  both  IP  address  and  port.  A  class  C  address 

space  is  chosen  and  the  last  octet  is  randomized  along  with  the  choice  of 
port  (1-65535).  The  jitter  introduced  in  this  trace  is  high,  with  delay  between 
packets  uniformly  distributed  within  the  range  [5e-6s,  0.016s]. 

4.1.2  Stealth  Activity 

Recall  that  stealth  activity  includes  slowing  the  rate  of  packet  arrival,  hiding  one’s  identity 
in  a  large  amount  of  decoy  traffic,  and  using  other  compromised  hosts  to  perform  a  scan. 

A  slow,  randomized  IP  block  scan  is  not  included  in  the  reference  data  due  to  the  size  of  the 
required  file.  Distributed  scans  were  also  not  present  in  the  DREnet  data  and  were  crafted. 

4.1 .2.1  Slow  Horizontal  Scans 

Filename:  scan_H_TCP_slow_ran.tcp 

Source:  DREnet,  6  December  2002 

Duration:  72h  39m  3.7s 

Description:  A  very  slow  TCP  SYN  scan  consisting  of  456  packets  to  port  80  on  160 
unique  hosts  residing  on  3  class  B  subnets.  The  average  time  interval  be¬ 
tween  probes  is  9.56  minutes.  The  randomization  of  IP  addresses  is  shown  in 
Figure  7. 
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Trace  info:  456  packets,  161  IP  addresses 


x  10 

Figure  7:  Very  slow,  randomized  scan  of  3  class  B  networks.  Each  dot  consists  of  3 
connection  attempts. 
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Filename: 

Source: 

Duration: 

Description: 


Filename: 

Source: 

Duration: 

Description: 


Filename: 

Source: 

Duration: 

Description: 


scan  ji_TCP_slow_ran_toolsig.tcp 
DREnet,  29  April  2001 
9h  25m  27.8s 

A  very  slow  TCP  SYN  scan  consisting  of  17  packets  to  port  515  on  17  unique 
hosts  residing  on  3  class  B  subnets.  The  order  of  the  IP  addresses  appeal's 
to  be  randomized,  as  does  the  time  interval  between  probes.  The  average 
time  interval  is  33.36  minutes.  The  attack  tool  used  to  perform  the  scan, 
myscan  [31],  is  easily  identifiable  through  a  constant  source  port  of  10101 
and  sequence  number  of  100. 


scan_FLUDP_slow_seq.tcp 
Crafted  (simHPortScan.cc) 

6d  17h  8m  41.1s 

A  slow  UDP  scan  to  port  69  (tftp).  65023  packets  are  sent,  with  delays  uni¬ 
formly  distributed  within  the  interval  [8.7s,  9.  Is],  to  65023  unique  destination 
IP  addresses.  A  packet  drop  rate  of  0.4%  was  introduced. 


scan  H  ICMPACK  slow  ran.tcp 
DREnet,  29  April  2001 
12h  56m  40.2s 

Slow  ICMP  and  ACK  combined  scan.  The  probes  come  in  pairs,  with  an  echo 
request  to  the  host  followed  by  an  ACK  packet  to  port  80  originating  from  port 
50990  or  50991.  1 1  hosts  from  3  class  B  subnets  are  scanned  in  random  order, 
with  an  average  time  interval  between  packets  of  24.27  minutes. 


4.1 .2.2  Slow  Strobe  Scan 


Filename: 

Source: 

Duration: 

Description: 


scan_S_TCP_slow_seq.tcp 
Crafted  (simStrobeScan.pl) 

34h  6m  27.5s 

A  slow  TCP  SYN  scan  is  performed  on  a  class  C  network.  A  set  of  packets 
aimed  at  12  commonly-used  services  is  sent  with  uniformly  distributed  delay 
between  packets  within  the  range  [10s,  70s]  (75%  jitter  with  an  average  delay 
of  40s)  to  254  unique  destination  IP  addresses. 


4.1 .2.3  Slow  Vertical  Scans 


Filename: 

Source: 

Duration: 

Description: 


scan_V_TCP_slow_seq.tcp 
Crafted  (simPortScan.pl) 

34h  14m  32.3s 

A  slow  ordered  scan  of  ports  1-1024  with  with  delay  between  probes  uni¬ 
formly  distributed  within  the  range  [90s,  150s]. 


Filename:  scan_V_TCP_slow_ran.tcp 
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Source:  Crafted  (simPortScan.pl) 

Duration:  65h  36m  9.3s 

Description:  A  very  slow  scan  of  ports  1-1024  in  random  order,  over  the  course  of  65 
hours.  The  delay  between  packets  is  uniformly  distributed  within  the  range 
[57.5s,  402.5s], 


4.1 .2.4  Needle  in  a  Haystack 


Filename: 

Source: 

Duration: 

Description: 


scan_H_TCP_fast_seq_needle.tcp 
DREnet,  8  December  2002 
6m  15.9s 

A  fast,  sequential  TCP  SYN  scan  for  ports  1243  and  27374  takes  attention 
away  from  two  other  IP  addresses  probing  the  same  ports.  The  large  scan 
sends  12371  packets  to  2439  unique  hosts  on  one  class  B  subnet  at  a  rate  of 
32.9  packets  per  second.  In  the  midst  of  this  traffic,  two  other  hosts  send 
probes  to  two  IP  addresses,  shown  by  the  green  and  blue  open  circles  in  Fig¬ 
ure  8. 


Trace  info:  12377  packets,  2444  IP  addresses 


Figure  8:  Needle  in  a  haystack.  A  large-scale  scan  attempts  to  conceal  directed  probes, 
shown  here  by  the  green  and  blue  open  circles. 

4.1 .2.5  Coordinated  Scans 

Filename:  scan_H_TCP_fast_seq_coordinated.tcp 
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Source:  DREnet,  8  December  2002 

Duration:  lh  lm  28.4s 

Description:  Three  class  B  networks  are  scanned  by  3  different  hosts.  A  TCP  SYN  scan 
is  performed  simultaneously  by  three  hosts,  each  scanning  a  single  class  B 
network  for  the  same  port.  All  scans  occur  approximately  in  sequence  (see 
Figure  9).  There  are  167363  packets  in  the  trace,  18  of  which  are  responses 
to  the  scan  (ICMP  and  TCP  reset).  The  scan  packets  arrive  at  an  average  rate 
of  45.37  packets/second  to  167327  unique  IP  addresses. 


Tracs  info:  167363  packets,  167328  IP  addresses 


Figure  9:  Coordinated  scan  of  3  class  B  networks.  The  different  origins  are  indicated  by 
different  colours. 


Filename:  scan  V  TCP  fast  ran  coordinated. tep 

Source:  Crafted  (simDistPortScanl.pl) 

Duration:  1.0s 

Description:  Each  of  13  source  hosts  probes  for  a  different  port  on  one  destination  host. 

The  probes  occur  over  a  1  second  interval  with  delay  between  packets  at  an 
average  of  1/1 3s  with  75%  jitter,  or  within  the  interval  [0.01925s,  0.13462s]. 


Filename:  scan_S_TCP_fast_ran_coordinated.tcp 

Source:  Crafted  (simDistPortScan2.pl) 

Duration:  1.0s 
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Description:  A  group  of  13  attackers  coordinate  their  efforts  in  this  attack.  Each  attacker 
chooses  a  single  port  to  focus  on,  and  scans  the  set  of  target  hosts  for  this  port. 
The  time  delay  between  probes  (against  42  hosts)  averages  l/545s  with  75% 
jitter,  or  uniformly  distributed  in  the  interval  [0.000459s,  0.003211s]. 


Filename: 

Source: 

Duration: 

Description: 


scan_H_TCP_fast_ran_coordinated.tcp 
Crafted  (simDistPortScan3.pl) 

2.3s 

Each  of  13  attackers  target  a  different  host  on  the  target  network.  A  single 
probe  (TCP  SYN  to  port  21)  is  sent  from  each  attacker  to  its  chosen  target. 
The  probes  arc  spaced  on  average  2/13s  apart  with  75%  jitter,  or  uniformly 
distributed  on  the  interval  [0.03846s,  0.26924s]. 


4.1.3  Traceroute 


Filename: 

Source: 

Duration: 

Description: 


traceroute. tcp 
DREnet,  30  August  2000 
lm  25.6s 

UDP  packets  are  sent  from  one  host  to  one  host,  with  the  TTL  starting  at  1 
and  increasing  until  it  reaches  17.  This  is  consistent  with  the  traceroute  tool, 
used  to  determine  the  path  that  packets  take  to  reach  a  host. 


4.1.4  OS  Identification 


Filename: 

Source: 

Duration: 

Description: 


fingerprint,  tcp 
DREnet,  30  August  2000 
0.1s 

One  host  is  probed  with  packets  consistent  with  the  QueSO  OS  fingerprint 
tool:  TCP  packets  with  the  SYN,  SYN-ACK,  FIN,  FIN-ACK,  SYN-FIN,  PSH 
and  finally  SYN  with  the  two  reserved  bits  set.  The  responses  generated 
include  2  RST  packets. 


4.1 .5  Vulnerability  Assessment  Tools 


Filename: 

Source: 

Duration: 

Description: 


cybercop.tcp 
DREnet,  30  August  2000 
27m  8.9s 

Pattern  of  behaviour  corresponding  to  the  CyberCop  vulnerability  assessment 
tool.  It  was  originally  designed  to  be  used  by  a  system  administrator  to  lock 
down  hosts  on  a  network,  but  it  may  be  used  by  an  attacker  to  try  to  determine 
vulnerabilities. 
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4.1.6  Possible  False  Positives 


The  true  purpose  of  the  following  traces  cannot  be  positively  determined.  They  may  be  TCP 
reset  scans,  or  they  may  be  backscatter  effects  as  the  result  of  either  needle-in-the-haystack 
scanning  activity  or  denial  of  service. 


Filename: 

Source: 

Duration: 

Description: 


backscatterl  .tcp 
DREnet,  29-30  August  2000 
23h  34m  38.3s 

Six  unique  IP  addresses  send  5330  TCP  RST  packets  to  166  unique  desti¬ 
nation  IP  addresses  on  3  class  B  networks.  The  source  ports  are  randomly 
distributed  between  900  and  9000,  and  the  destination  ports  appeal-  to  be  uni¬ 
formly  distributed  between  0  and  65536.  The  packets  arrive  at  an  average  rate 
of  one  packet  every  15.9  seconds. 


Filename: 

Source: 

Duration: 

Description: 


backscatter2.tcp 
DREnet,  29  April  2001 
21m  57.8s 

One  source  IP  address  sends  9  TCP  RST  packets  to  9  unique  destination  IP 
addresses  on  3  class  B  networks  at  an  average  rate  of  one  packet  every  15.9 
seconds.  The  destination  ports  are  >  1023,  as  is  all  but  one  source  port.  After  a 
90  second  pause,  this  activity  is  followed  by  520  TCP  RST  packets  sent  to  520 
unique  IP  address  on  3  class  B  networks,  with  source  port  0  and  destination 
port  either  1024  or  3072  at  an  average  rate  of  one  packet  every  2. 1  seconds. 


4.2  Escalation 

Password  cracking  and  session  hijacking  were  not  found  in  the  DREnet  traffic  and  traces 
were  incomplete  in  the  DEFCON  traffic.  These  types  of  attacks  were  simulated  on  a  lab 
network  or  crafted. 


4.2.1  Password  Cracking 


Filename: 

Source: 

Duration: 

Description: 


offline  _passwd.  tcp 
Closed  network 
5h  39m  47.1s 

Offline  password  cracking.  On  a  closed  network,  /etc/pas  swd  and  /etc/ shadow 
are  retreived  via  a  misconfigured  FTP  server,  the  password  for  root  is  cracked 
locally,  and  then  the  attacker  logs  in  as  root  via  SSH  at  a  later  time.  Note 
that  the  retrieval  and  SSH  sessions  are  contained  in  2  separate  files  in  the 
merged  versions  due  to  the  large  interval  of  inactivity:  offline _passwd_l. tcp 
and  offline_passwd_2.tcp. 


Filename:  online_passwd.tcp 
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Source: 

Duration: 

Description: 


Closed  network 
5.2s 

Online  password  cracking.  On  a  closed  network,  a  scripted  attack  was  run 
that  reads  each  line  of  a  password  "dictionary”  and  sends  this  password  as 
an  argument  to  a  mysql  login  attempt.  Further  description  is  contained  in  the 
script  created  to  simulate  the  attack,  dictAttack.pl  (Section  B.l). 


4.2.2  Buffer  Overflow 


Filename: 

Source: 

Duration: 

Description: 


buffer.tcp 

DEFCON 

0.03s 

A  buffer  overflow  is  attempted  on  TCP  port  53  in  an  attempt  to  get  a  shell  with 
root  access.  In  the  content,  it  can  be  seen  that  the  attacker  has  actually  broken 
up  the  /bin/sh  string  to  avoid  detection  by  an  IDS.  However,  the  large  num¬ 
ber  of  x86  NOP  instructions  (hexadecimal  value  0x90)  is  a  signature.  Note 
that  the  merged  data  contains  only  a  144  byte  data  capture  length. 


4.2.3  Priveleged  File  Access 


Filename: 

Source: 

Duration: 

Description: 


webprobe.tcp 
DREnet,  30  August  2000 
lh  34m  30.9s 

Attempts  arc  made  to  access  several  dangerous  files  on  a  web  server,  such  as 

/cgi-bin/sh  and  scripts/cmd.exe. 


4.3  Denial  of  Service 

Denial  of  service  attacks  were  not  found  in  the  DREnet  data  and  were  incomplete  in  the 
DEFCON  data.  The  reference  data  contains  data  collected  on  a  closed  network,  generated 
using  publicly-available  tools. 

4.3.1  Vulnerability  DoS 

The  following  traces  contain  denial  of  service  attempts  that  rely  on  a  vulnerability  within 
the  TCP/IP  stack. 


4.3.1 .1  Land  Attack  DoS 


Filename: 

Source: 

Duration: 

Description: 


land.tcp 
Closed  network 
N/A  (single  packet) 

The  land .  c  code  was  compiled  and  launched  on  a  closed  network.  The  attack 
consists  of  sending  a  TCP  SYN  packet  to  the  victim,  where  the  return  IP 
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address  has  been  forged  to  be  identical  to  the  target  IP  address.  The  land 
attack  will  crash  some  older  operating  systems. 


4.3.1 .2  Teardrop  DoS 


Filename: 

Source: 

Duration: 

Description: 


teardrop.tcp 
Closed  network 
0.9s 

The  teardrop .  c  code  was  compiled  and  launched  on  a  closed  network.  The 
attack  involves  IP  fragmentation:  an  IP  packet  fragment  is  sent  with  an  offset 
specified  to  overwrite  the  data  supplied  by  the  previous  fragment.  When  the 
packet  is  reassembled  at  the  target  address,  some  older  operating  systems 
crash.  The  attack  in  this  example  uses  two  fragments  of  one  packet,  and  the 
packet  is  sent  repeatedly. 


4.3.2  Multipacket  DoS 

The  following  traces  contain  denial  of  service  attempts  that  rely  on  reseource  starvation  or 
on  congestion. 


4.3.2. 1  Smurf  DoS  Attack 

Several  scripts  and  programs  were  written  to  craft  traces  which  would  have  been  generated 
by  the  Smurf  tool  (see  Section  B.3).  The  following  attacks  were  simulated. 


Filename: 

Source: 

Duration: 

Description: 


smurf  l.tcp 

Crafted  (simSmurfl.ee) 

N/A  (single  packet) 

An  unsuccessful  attempt  to  use  our  network  to  smurf  a  target.  An  ICMP  echo 
request  packet  is  directed  to  a  broadcast  IP  address,  with  no  reply. 


Filename: 

Source: 

Duration: 

Description: 


smurf2.tcp 

Crafted  (simSmurf2a.cc  simSmurf2b.cc  simSmurf2.pl) 

16m  42.2s 

Our  network  is  used  to  smurf  a  target.  ICMP  echo  request  packets  are  directed 
to  a  broadcast  address  at  a  rate  of  10  per  second,  with  delay  between  packets 
in  the  interval  [0.07s,  0.13s]  and  a  packet  drop  rate  of  1%.  Existing  hosts  reply 
to  the  spoofed  source  address.  It  is  assumed  that  25%  of  the  available  address 
space  is  used  (60  hosts).  Each  host  has  its  own  characteristic  delay  d,  ranging 
from  0.14ms  to  0.5ms.  Approximatly  10000  echo  reqests  are  received.  The 
hosts  on  the  local  network  respond  to  each  packet  with  a  0.5%  chance  of 
dropping  the  reply  packet,  with  a  delay  between  replies  uniformly  distributed 
in  the  interval  [d,  2d]. 
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Filename: 

Source: 

Duration: 

Description: 


smurf3.tcp 

Crafted  (simSmurf3a.pl) 

5m  1.7  s 

A  smurf  attack  is  directed  at  us.  184059  ICMP  echo  reply  packets  are  sent  to 
us  from  a  class  C  subnet  containing  62  nodes.  Each  node  sends  packets  with 
delay  uniformly  distributed  within  the  interal  [0.08s,  0.12s]  (averaging  610 
packets  per  second),  with  a  packet  drop  rate  of  1%. 


4. 3. 2. 2  TCP  SYN  Flood  DoS 

Filename:  synful.tcp 

Source:  Closed  network 

Duration:  1.5s 

Description:  The  exploit  program  synful .  c  was  compiled  and  launched  on  a  closed  net¬ 
work.  20010  TCP  SYN  packets  were  sent  to  port  80  on  one  destination  IP 
address  at  a  rate  of  13485.9  packets  per  second.  The  packets  were  spoofed  to 
have  20010  unique  source  IP  addresses;  the  random  distribution  of  spoofed 
source  IP  addresses  is  shown  in  Figure  10. 


Trace  info:  20010  packets,  20011  IP  addresses 


Figure  10:  A  DoS  performed  by  the  tool  synful.  The  uniform  distribution  of  randomly 
generated  source  IP  addresses  are  shown;  the  target  is  the  solid  line. 
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4. 3. 2. 3  Distributed  Denial  of  Service 


Filename: 

Source: 

Duration: 

Description: 


tfn2k.tcp 

Closed  network  and  crafted  (even .  pi) 
lm  46.0s 

The  DDoS  exploit  program  tribal  flood  network  2000  was  compiled  and  launched 
on  a  closed  network  with  one  host  acting  as  both  the  master  and  slave,  and 
the  other  acting  as  victim.  250000  packets  were  collected  five  times,  result¬ 
ing  in  5  separate  traces  representing  5  slaves.  The  TTL  values  for  each  trace 
were  modified  to  reflect  slaves  positioned  at  5,  8,  12,  17  and  20  hops  distance 
from  the  victim.  The  files  were  merged  and  the  timestamps  stretched  such 
that  a  5  Mbps  line  would  be  just  exceeded.  This  data  was  combined  with  the 
clean  data,  and  packets  were  dropped  to  reflect  the  5  Mbps  limit.  This  data  is 
presented  as  the  merged  data,  and  the  DDoS  traffic  was  extracted  to  give  the 
clean  DDoS  data. 


4.4  Covert  Data  Transfer 

We  include  covert  communications  that  can  either  send  data  or  embed  data  within  an  image. 

4.4.1  Covert  Tunnels 

The  commands  transferred  via  the  tunnels  in  the  traces  arc  as  follows: 

1.  echo  “hello” 

2.  Is 

3.  pwd 

4.  Is  /etc 

5.  cat /etc/passwd 

4.4.1 .1  ICMP  Tunnels 

The  loki  software  had  to  be  modified  before  it  could  be  compiled:  in  loki  .h,  the  ip.h  and 
icmp.h  include  statements  were  reversed,  and  signals.h  was  changed  to  be  from  the  sys 
directory  rather  than  linux.  The  Makefile  was  modified  to  remove  the  DEBUG  mode. 


Filename: 

Source: 

Duration: 

Description: 


loki-nocrypt.tcp 
Closed  network 
13.3s 

The  loki  ICMP  tunnel  software  was  compiled  on  a  client  and  a  server  with  no 
encryption.  The  daemon  was  started  on  the  server,  then  the  client  executed 
remote  commands. 
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Filename: 

Source: 

Duration: 

Description: 


loki-weakcrypt.tcp 
Closed  network 
10.6s 

The  loki  ICMP  tunnel  software  was  compiled  on  a  client  and  a  server  with 
weak  encryption.  The  daemon  was  started  on  the  server,  then  the  client  exe¬ 
cuted  remote  commands. 


4.4.2  Information  Hiding 

The  information  hiding  examples  embed  the  secret  message  “The  golden  eagle  has  landed.” 

4.4.2. 1  Steganography 

The  steganography  tool  gifshuffle  [32]  was  used  to  embed  a  message  in  a  gif  image.  The 
original  image,  drdc-splash4  .gif,  was  modified  to  include  the  secret  message.  The  re¬ 
sulting  image  is  stored  in  drdc-splash4-stego.gif. 

4.4. 2. 2  TCP/IP  Fields 

The  covert_tcp .  c  code  [20]  was  installed  on  a  client  and  a  server  on  a  closed  network. 


Filename: 

Source: 

Duration: 

Description: 


covert  _tcp  Jpid.closedport.tcp 

Closed  network 

28.3s 

The  secret  phrase  was  transferred  using  the  IP  ID  header  field.  The  data  was 
sent  to  a  closed  port. 


Filename:  covert  _tcp  jpid.openport.  tcp 

Source:  Closed  network 

Duration:  2m  6.5s 

Description:  The  secret  phrase  was  transferred  using  the  IP  ID  header  field.  The  data  was 
sent  to  an  open  port,  resulting  in  a  much  longer  trace  due  to  the  replays  of 
SYN/ACK  packets. 


Filename: 

Source: 

Duration: 

Description: 


covert_tcp_seq_closedport _slower.  tcp 
Closed  network 
4m  40.3s 

The  secret  phrase  was  transferred  using  the  TCP  sequence  number  header 
field.  The  data  was  sent  to  a  closed  port.  The  source  code  was  modified  to 
increase  the  sleep  time  between  packet  transmissions. 


Filename:  covert  _tcp  _seq_openport .  tcp 
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Source:  Closed  network 

Duration:  2m  5.3s 

Description:  The  secret  phrase  was  transferred  using  the  TCP  sequence  number  header 
field.  The  data  was  sent  to  an  open  port,  resulting  in  a  much  longer  trace  due 
to  the  replays  of  SYN/ACK  packets. 


Filename: 

Source: 

Duration: 

Description: 


covert  _tcp  _seq_bounced.  tcp 
Closed  network 
3m  19.5s 

The  secret  phrase  was  transferred  using  the  TCP  sequence  number  header 
field.  The  “bounced”  option  was  used  for  this  trace:  the  data  was  sent  to  an 
open  port  on  an  intermediate  host,  with  forged  source  IP  address.  The  replies 
were  then  directed  from  the  intermediate  host  to  the  server  for  interpretation. 
The  trace  appeal's  to  originate  from  internal  addresses. 


5  Discussion 


Collecting  an  exhaustive  set  of  network  attacks  is  not  practical.  In  this  work,  we  have 
attempted  to  collect  a  wide  assortment  of  attacks,  particularly  attempting  to  cover  a  variety 
of  attributes  for  the  reconnaissance  family.  As  the  need  arises,  more  attacks  will  be  added 
to  the  data  set,  such  as  HTTP  tunnels  or  man-in-the -middle  PKI  attacks.  Wireless  protocols 
could  also  be  captured.  This  data  is  meant  to  serve  as  a  starting  point,  to  provide  a  basic  set 
of  known  attacks  to  test  IDS  and  visualisation  methodologies. 

By  using  the  same  set  of  ambient  traffic  to  create  the  merged  data  set,  we  have  the  advantage 
of  a  controlled  variable  among  the  attacks.  The  drawback,  of  course,  is  that  there  is  less 
variety  in  the  types  of  legitimate  ambient  traffic.  The  cleaned  ambient  traffic  may  also  have 
been  over-pruned:  the  TCP  FSM  also  removes  traffic  that  is  “normal”  but  not  malicious, 
e.g.  misconfigurations.  This  may  not  meet  the  user  requirements.  Even  so,  the  ambient 
traffic  cannot  be  guaranteed  to  be  totally  clean. 

In  removing  the  content  of  the  ambient  traffic,  we  also  removed  information  that  may  be 
useful  in  testing  the  methods.  This  could  not  be  helped  as  it  was  necessary  to  protect  the 
privacy  of  DREnet  users. 


6  Conclusion  and  Recommendations 


This  report  has  documented  the  network  attack  reference  data  set  created  via  custom  soft¬ 
ware  at  DRDC.  The  software  is  capable  of  manipulating  IP  traffic  traces  in  pcap  format, 
including  header  fields  such  as  IP  address  and  time-to-live,  as  well  as  a  variety  of  ma¬ 
nipulations  of  the  timestamp  such  as  jitter,  time  shifting,  compression  or  expansion.  The 
software  is  also  capable  of  merging  two  or  more  traffic  traces  with  interleaved  timestamps, 
essential  for  inserting  attack  traces  into  normal  traffic. 
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The  resulting  network  attack  reference  data  set  can  be  used  to  test  the  limits  of  intrusion 
detection  systems  and  to  test  new  intrusion  detection  techniques  and  network  traffic  visual¬ 
isation  techniques.  The  reference  data  set  should  be  continually  updated  with  new  attacks. 
The  capabilities  of  the  software  have  been  included  in  DRDC’s  Network  Traffic  Analysis 
Toolbox  [33]  as  powerful  packet  and  trace  manipulation  functions. 
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Annex  A 

TCPUtils  Source  Code 


TCPUtils  is  a  set  of  programs  which  were  written  to  facilitate  the  manipulation  of  pcap 
files.  They  rely  on  TCPLib  to  read  and  write  the  packet  traces. 


A.1  TCPMerge  (tcpmerge  .  cc) 

TCPMerge  is  used  to  join  several  pcap  files  together.  Unlike  Tcpslice,  the  input  files  arc 
allowed  to  have  interleaved  timestamps.  Care  should  be  taken  to  ensure  that  input  files  have 
the  same  packet  capture  length.  TCPTruncate  can  be  used  to  accomplish  this. 

A. 2  TCPIPTranslate  (tcpiptranslate .  cc) 

TCPIPTranslate  is  used  to  replace  one  IP  in  a  trace  with  another.  It  will  also  recalculate  the 
checksum  to  ensure  proper  packets  arc  generated.  More  than  one  IP  can  be  exchanged  if 
there  are  more  than  one  pair  of  IP  addresses  listed  on  the  command  line. 

A. 3  TCPTTLTranslate  (tcpttltranslate  .  cc) 

TCPTTLTranslate  is  used  to  alter  the  TTL  (time  to  live)  fields  in  IP  packets.  A  value 
specified  on  the  command  line  is  added  to  the  TTL  fields  in  all  IP  packets  of  the  specified 
trace.  The  IP  checksum  is  recalculated  to  ensure  a  proper  trace  is  produced.  The  value  by 
which  the  TTL  is  modified  may  be  negative. 

A.4  TCPTimeShift  (tcptimeshift .  cc) 

TCPTimeShift  modifies  time  stamps  in  a  packet  trace  to  make  the  trace  appeal-  as  if  it  oc¬ 
curred  at  a  different  time.  All  time  stamps  are  altered  by  the  same  amount  (specified  on  the 
command  line).  Time  stamps  may  be  moved  either  forward  or  backward  in  time. 

A.5  TCPTimeStretch  (tcptimestretch.cc) 

TCPTime Stretch  will  scale  the  difference  in  time  between  packets.  This  can  be  used  to 
compress  or  expand  traces  to  simulate  the  appearance  of  a  faster  or  slower  connection.  The 
time  stamp  of  the  first  packet  is  preserved. 

A.6  TCPTruncate  (tcptrunc .  cc) 

TCPTruncate  will  reduce  the  captured  data  length  in  pcap  files.  This  is  useful  if  the  merging 
of  files  is  desired,  and  one  trace  has  a  higher  capture  length  (pcap  snap  length)  than  the  other. 


32 


DRDC  Ottawa  TM  2004-242 


A.7  TCPJitter  (tcp  jitter .  cc) 

TCP  Jitter  can  be  used  to  add  randomness  to  packet  traces.  This  is  especially  useful  when 
working  with  crafted  traces,  as  the  results  of  such  crafting  arc  usually  idealized,  and  ran¬ 
domness  can  make  them  appear  more  realistic.  This  program  can  accept  two  types  of 
arguments  —  a  time  jitter  factor,  and  a  drop  rate.  If  a  time  jitter  factor  is  specified  on  the 
command  line,  the  program  will  randomly  add  or  subtract  time  between  packets,  up  to  a 
maximum  specified  percentage.  If  a  drop  rate  is  specified,  then  each  packet  will  have  this 
percentage  chance  of  being  dropped  (left  out  of  the  output  trace). 

A.8  TCPRate  (teprate  .  cc) 

Useful  for  analyzing  potential  packet  flood  attacks,  TCPRate  will  output  a  table  of  bytes 
transfered  in  each  second  of  a  trace.  This  table  is  suitable  for  plotting  in  programs  like 
gnuplot. 

A. 9  TCPContent  (tcpcontent .  cc) 

TCPContent  will  output  the  ASCII  representation  of  TCP  or  IP  packets.  This  utility  is 
extremely  useful  for  determining  an  attacker’s  actions  when  a  text  based,  non-encrypted 
protocol  (like  HTTP  or  FTP)  is  used. 

A.10  TCPTimeSpace  (tcptimespace .  cc) 

The  TCPTimeSpace  utility  will  evenly  space  out  packets  occurring  in  the  same  second.  This 
is  particularly  useful  when  working  with  files  generated  by  scripts  which  have  many  differ¬ 
ent  packets  occurring  at  exactly  the  same  point  in  time  (such  as  the  coordinated  scans). 
TCPTimeSpace  is  typically  used  with  TCPJitter  to  simulate  packets  arriving  at  various 
points  in  time. 
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Annex  B 

Simulation  Script  and  Program  Source  Code 


Many  of  the  simulated  attacks  were  performed  using  Perl  scripts  and  custom  C++  programs. 
Also  listed  in  this  section  is  the  Makefile  which  automates  the  build  process  of  the  TCPLib, 
TCPUtils  and  C++  attack  simulation  utilities. 

B.1  Online  Password  Cracking 

B.1.1  dictAttack.pl 

# !  /usr/bin/perl 

#  Jason  McKenna,  summer  2003. 

#  Script  to  help  simulate  a  dictionary  attack 

#  Will  read  in  passwords  from  file,  pass  them  to  mysql  client  which  will  attempt 

#  to  login  using  the  password.  A  return  code  of  0  means  the  password  was 

#  correct.  We  assume  that  the  attacker  already  knows: 

#  a)  there  is  a  mysql  server  running  on  the  port 

#  b)  there  is  a  database  named  "data" 

#  c)  there  is  a  user  named  "jason" 

#  d)  jason  has  permission  to  login  from  anywhere  from  the  Internet 

#  open  the  password  file 
open  FH,  "passwords"; 

#  set  flag  to  false  (not  really  required  as  already  0  but...) 

#  and  it's  better  practice  to  exit  at  end  of  program,  rather  then  quit  in 

#  middle 
$done  =  0; 

#  read  lines  while  we  haven't  found  password 
while  (($pass  =  <FH>)  &&  ($done  ==  0))  { 

#strip  endline  from  password 
$pass  =~  s/\n//; 

#try  to  log  in  (and  quit  if  successful) 

system  "echo  \\\\q  |  mysql  -u  jason  -p$pass  -h  192.168.2.8  data  >  /dev/null 
2>&1" ; 

if  ($?  ==  0)  { 

print  "Found  password:  $pass\n"; 

$done  =  1; 

} 

} 

if  ($done  ==  0)  { 

print  "Could  not  find  password. \n"; 

} 

B.2  Scan  Generators 

B.2.1  simDistPortScanl.pl 

# !  /usr/bin/perl 

#Simulate  many  hosts  scanning  1  host,  many  ports 
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lamount  to  jitter  the  timestamps 
$jitter  =  75; 

#modified  to  obsificate  DREnet  IP 
$net  =  "172.168"; 

#  these  addresses  are  random  and  may  or  may  not  resolve  to  actual  computers 

#  on  the  internet 

%scanners  =  ("24.42.204.111"  =>  7,  "24.56.221.241"  =>  21,  "181.61.24.66"  =>23,  "198 .224 . 55 . 10"=>53,  "17.22.120.134"  =>  8 
$ver  =  1; 

#what  hosts  on  $net  to  simulate  the  attack  against. 

Otargets  =  ("251.1"); 

$outfile  =  "distPortScan$ver .tcp"; 

#each  attacer  will  probe  the  appropiate  ports  on  each  victim 
foreach  $attacker  (keys  %scanners)  { 
foreach  $victim  (Otargets)  { 

$file  =  "distPortScan$ver . $attacker . $victim. tcp" ; 

print  "$attacker  scanning  $net.$victim  port  @scanners{$attacker}\n"; 

system  (" . /simPortScan  $file  $attacker  $net.$victim  Oscanners { $attacker }  Oscanners {$attacker}  1"); 

$filelist  .=  "  $file"; 

} 

} 


#create  thie  final  file  by  merging  together  all  the  generated  files 
system  "tcpmerge  $filelist  $outfile"; 
system  "rm  $filelist"; 

system  "tcptimespace  $outfile  a$outfile";  #space  out  the  packets  evenly  (impose  gaps  between  packets  occurint  at  same  ti 
system  "tcpjitter  a$outfile  $outfile  t$jitter"; 


B.2.2  simDistPortScan2.pl 

# !  /usr/bin/perl 

#Jason  McKenna,  summer  2003 

#Simulate  many  hosts  scanning  many  hosts,  many  ports 
$jitter  =  75; 

#modified  to  obsificate  DREnet  IP 
$net  =  "172.168"; 

%scanners  =  ("24.42.204.111"  =>  7,  "24.56.221.241"  =>  21,  "181.61.24.66"  =>23,  "198 .224 . 55 . 10"=>53,  "17.22.120.134"  =>  8 
$ver  =  2; 

^targets  =  ("251.1"  , "240.145", "240.150", "240.151", "242.4", "242 . 3", "242 . 18", "242.200", , "241 . 16" , "241 . 4", "244 . 2" , "244.3", 
$outfile  =  "distPortScan$ver .tcp"; 

#generate  the  scan  that  each  attacker  performs  against  each  victum 
foreach  $attacker  (keys  %scanners)  { 
foreach  $victim  (Otargets)  { 

$file  =  "distPortScan$ver . $attacker . $victim. tcp" ; 

print  "$attacker  scanning  $net.$victim  port  @scanners{$attacker}\n"; 

system  ("./simPortScan  $file  $attacker  $net.$victim  Oscanners { $attacker }  Oscanners {$attacker }  1"); 

$filelist  .=  "  $file"; 

} 

} 

system  "tcpmerge  $filelist  $outfile"; 
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system  "rm  $filelist"; 

system  "tcptimespace  $outfile  a$outfile"; 
system  "tcpjitter  a$outfile  $outfile  t$jitter"; 


B.2.3  simDistPortScan3.pl 

# !  /usr/bin/perl 

#  Jason  McKenna,  summer  2003 
$jitter  =  75; 

#modified  to  obsificate  DREnet  IP 
$net  =  "172.168"; 

#Simulate  many  hosts  scanning  many  hosts,  1  port 

%scanners  =  ("24.42.204.111"  =>  "240.151",  "24.56.221.241"  =>  "242.4",  "181.61.24.66"  =>"242.3",  "198 . 224 . 55 . 10"=>"242 . 1 
$ver  =  3; 

$port  =  21; 

$outfile  =  "distPortScan$ver .tcp"; 

#each  attacker  scans  for  port  21  on  the  host  it  is  associated  with  in  the  hash 
foreach  $attacker  (keys  %scanners)  { 

$victim  =  Oscanners { $attacker } ; 

$file  =  "distPortScan$ver . $attacker . $victim. tcp" ; 

print  "$attacker  scanning  $net.$victim  port  $port\n"; 

system  (" . /simPortScan  $file  $attacker  $net.$victim  $port  $port  1"); 

$filelist  .=  "  $file"; 

} 

#merge  all  files 

system  "tcpmerge  $filelist  $outfile"; 
system  "rm  $filelist"; 

system  "tcptimespace  $outfile  a$outfile"; 
system  "tcpjitter  a$outfile  $outfile  t$jitter"; 


B.2.4  simPortScan.cc 

/*  Copyright 

*  (C)  Her  Majesty  the  Queen,  as  represented  by  the  Minister  of  National  Defence, 

*  2003 

*  (C)  Sa  majeste  la  reine,  representee  par  le  ministre  de  la  Defense  nationale, 

*  2003 

*  Written  by  Jason  McKenna,  summer  2003  for  DRDC 
*/ 


/*  simPortScan.cc 

Simulates  a  port  scan  from  one  host  vs  another. 

Specified  IP  will  scan  another  specified  IP  for  open  TCP  ports  in  a  range 
also  specified  on  the  command  line. 

usage : 

simPortScan  <file>  <sourceIP>  <destIP>  <startPort>  <endPort>  <speed>  [-r] 

where  <file>  is  the  file  created,  <sourceIP>  and  <destIP>  are  the  IPs  involved, 
<startPort>  and  <endPort>  specify  the  rang  eof  ports  to  scan,  <speed>  determines 
the  rate  at  which  to  scan,  and  the  optional  [-r]  randomised  the  order  in  which 
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to  scan. 


*/ 

#include  "tcplib.h"  //use  the  TCPLib  to  write  PCap  files. 

#include  <iostream.h> 

#include  <stdlib.h> 

#include  <sys/time.h> 

#include  <time.h> 

#include  <unistd.h> 

#define  TTL  111  //default  TTL  if  none  specified  on  cmd  line 
#define  PACKETLEN  54 

#define  TIME_STAMP_START  1055936617  //  About  7:45,  June  18,  2003 

#define  RAND_DELTA  0x7fffffff  //used  to  flag  that  you  want  random  generated 

#define  IP_ID_INIT  25338 

#define  IP_ID_DELTA  256  //256  is  typical  for  Win  machines,  1  or  random  typical 

//for  *nix  —  set  to  RAND_DELTA  if  you  want  a  random  ip  id  delta 

#define  IPJTOS  0x10 

#define  IP_DONT_FRAG  true 

#define  IP_MORE_FRAG  false 

#define  TCP_SRC_PORT_INIT  3605 

#define  TCP_SRC_PORT_DELTA  RAND_DELTA  //set  to  RAND_DEL1A  for  random  src  port 

#define  TCP_SYN  true 

#define  TCP_SEQ_INIT  48837445 

#define  TCP_SEQ_DELTA  15  //set  to  RAND_DELTA  for  random  seq  # 

#define  TCP_WINDOW  8192 
#define  POS_FILE  1 
#define  POS_SOURCE  2 
#define  POS_DEST  3 
#define  POS_START  4 
#define  POS_END  5 
#define  POS_SPEED  6 
#define  POS_RANDOM  7 

void  displayHelp ( ) ; 

int  main(int  argc,  char  **  argv)  { 
struct  timeval  tm; 
gettimeofday (&tm, NULL) ; 
srand(getpid() ) ; 
srand(tm.tv__usec) ; 

uint8_t  smac[6]  =  {0x00,  0x08,  0xe3,  0x17,  OxdO,  0x90  };  //source  mac 
//  for  packets  {hardware  addr  of  router) 

uint8_t  dmac[6]  =  {0x00,  OxeO,  Oxle,  0xa5,  0x14,  0xe2  };  //dest  mac  for 
//  packets  {harware  addr  of  firewall  or  server,  depending 
//  on  how  firewall  is  configured) 

//did  user  ask  for  help 

for  (int  i  =  1;  i  <  argc;  i++)  { 

if  (strcmp (argv [i] ,  "-h")  ==  0  I  strcmp (argv[i] , " — help")  ==  0)  { 
cout  <<  "a"  «  endl; 
displayHelp () ; 
return  0; 

) 

} 

//did  user  enter  incorrect  args 
if  ((argc  !=  7)  &&  (argc  !=  8))  { 

cout  <<  "b"  <<  endl; 
displayHelp () ; 
return  1; 

) 
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//get  the  first  and  last  port 

int  startPort  =  atoi (argv [POS_START] ) ; 

int  endPort  =  atoi (argv [POS_END] ) ; 

if  (endPort  <  startPort)  { 

int  temp  =  endPort; 

endPort  =  startPort; 

startPort  =  temp; 

} 

//fill  a  "port"  array  with  port  numbers 
uintl6_t  port [endPort  -  startPort  +  1]; 
for  (int  i  =  startPort;  i  <=  endPort;  i++)  { 
port [i-startPort ]  =  i; 

} 

//if  the  user  specif ed  an  extra  arg  on  cmd  line... 
if  (argc  ==  8)  { 

//if  arg  was  "-r",  randomize  order  of  ports 

if  ( st romp (argv [POS_RANDOM] ,  "-r")  ==  0)  { 

for  (int  i  =  0;  i  <=  (endPort  -  startPort);  i++)  { 

int  swapPos  =  rand()  %  (endPort  -  startPort); 

uintl6_t  temp  =  port [i] ; 

port[i]  =  port [swapPos] ; 

port [swapPos]  =  temp; 

} 

//otherwise,  display  help 
}  else  { 
displayHelp () ; 
return  1; 

} 

} 


//read  IPs  from  cmd  line 

uint32_t  sourcelP  =  strToIP (argv [POS_SOURCE] ) ; 
uint32_t  destIP  =  strToIP  (argv [POS_DEST] ) ; 

//read  the  speed  from  the  command  line 
float  f speed  =  atof (argv [POS_SPEED] ) ; 
if  (fspeed  ==  0.0)  { 

//if  user  entered  invalid  speed  (0  or  non-numeric); 
displayHelp () ; 
return  1; 

} 

if  (fspeed  <  0)  fspeed  =  -fspeed; 
int  delays  =  (int)  (1 . 0/fspeed) ; 

int  delayu  =  (int)  (1000000.0  /  (fspeed  -  ((float)  delays))); 

//seed  the  randomizer 
srand (time (NULL)  ) ; 

//create  the  file  header  to  be  used  in  the  output  file 

struct  pcap_file_header  fh; 

fh. magic  =  TCPDUMP_MAGIC; 

fh.pcap_version_ma jor=PCAP_VERSION_MAJOR; 

fh.pcap_version_minor=PCAP_VERSION_MINOR; 

fh.thiszone  =  0; 

fh.sigfigs  =  0; 

fh.snaplen  =  68; 

fh.linktype  =  1;  //ethernet 


TcplibFileWriter  *  writer  =  new  TcplibFileWriter (argv [POS_FILE] ,  fh) ; 
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TcplibTCPPacket  *  p  =  new  TcplibTCPPacket (PACKETLEN) ; 
struct  timeval  timestamp; 
gettimeofday (stimestamp,  NULL); 
timestamp.tv_sec  =  TIME_STAMP_START; 

//set  ethernet  header  info  (protocol  set  by  ip  constructor) 
p->setEthernetSourceMAC (smac) ; 
p->setEthernetDestMAC (dmac) ; 

//ip  ver,  ihl,  tos,  tot_len,  flags,  frag_offset,  protocol  set  by 
//  constructor 

p->setIPSourceAddress (sourcelP) ; 
p->setIPDestAddress (destIP) ; 
p->setIPTTL (TTL) ; 

p->setIPDontFragBit ( IP_DONT_FRAG) ; 
p->setIPMoreFragBit (IP_MORE_FRAG) ; 
p->setIPTypeOfService (IP_TOS) ; 
int  id  =  IP_ID_INIT; 
p->setTCPSynFlag (TCP_SYN) ; 
p->setTCPWindow (TCP_WINDOW)  ; 
int  sPort  =  TCP_SRC_PORT_INIT; 

if  (TCP_SRC_PORT_DELTA  ==  RAND_DELTA)  sPort  =  rand()  %  65536; 
int  seq  =  TCP_SEQ_INIT; 

//for  each  port  in  out  list... 

for  (int  i  =  0;  i  <=  (endPort  -startPort);  i++)  { 
p->setTimestamp (timestamp) ; 
p->setTCPDestPort (port [i] ) ; 
p->setTCPSourcePort  (sPort) ; 
p->setTCPSeqNum(seq) ; 
p->setIPID (id) ; 

p->setIPChecksum(p->calculateIPChecksum() ) ; 
int  sum  =  p->calculateTCPChecksum() ; 
p->setTCPChecksum (sum) ; 
writer->writePacket (p) ; 

//for  debug  purposes 

//cout  <<  "Wrote  packet  "  <<  i  «  endl; 

//get  packet  readey  for  next  write; 

//get  next  timestamp 
timestamp.tv_sec  +=  delays; 
timestamp.tv_usec  +=  delayu; 
if  (timestamp. tv_usec  >=  1000000)  { 
timestamp.tv_usec  -=  1000000; 
timestamp. tv_sec++; 

} 

//select  new  source  port 
if  (TCP_SRC_PORT_DELTA  ==  RAND_DELTA)  { 
sPort  =  rand()  %  65536; 

}  else  { 

//increment,  and  loop  if  appropiate 
sPort  +=  TCP_SRC_PORT_DELTA; 
if  (sPort  >=  65536)  { 
sPort  -=  65536; 

} 

} 

//select  new  tcp  seqence  # 
if  (TCP_SEQ_DELTA  ==  RAND_DELTA)  { 
seq  =  rand  () ; 

}  else  { 
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//increment,  and  loop  if  appropiate 
seq  +=  TCP_SEQ_DELTA; 

} 

//select  new  ip  id 
if  (IP_ID_DELTA  ==  RAND_DELTA)  { 
id  =  rand()  %  65536; 

}  else  { 

//increment,  and  loop  if  appropiate 
id  +=  IP_ID_DELTA; 
if  (id  >=  65536)  { 
id  -=  65536; 

} 

} 


} 

delete  p; 
delete  writer; 

cout  «  "Successful."  «  endl; 
return  0; 

} 

void  displayHelp ()  { 

cout  «  "simPortScan :  Generates  a  port  scan  vs  a  host"  <<  endl  <<  endl 

«  "usage:  simPortScan  <file>  <sourceIP>  <destIP>  <startPort>  <endPort>  <speed>  [ — r ] "  <<  endl  «  endl 

«  "  file:  name  of  file  to  output."  <<  endl 
«  "  source/destIP :  IP  address  of  attacker/target "  «  endl 
«  "  start /endPort :  Port  to  start  &  end  scan"  <<  endl 
«  "  speed:  Scan  speed  in  packets/second"  <<  endl 
«  "  -r:  (optional)  randomize  scan  order"  <<  endl  <<  endl 

«  "Compiled  with  TCPLib  "  «  TCPLIB_VERSION_MAJOR  «  "."  «  TCPLIB_VERSION_MINOR  «  «  TCPLIB_VERSION_EXTRA  « 

} 

B.2.5  simHPortScan.cc 

/*  Copyright 

*  (C)  Her  Majesty  the  Queen,  as  represented  by  the  Minister  of  National  Defence, 

*  2003 

*  (C)  Sa  majeste  la  reine,  representee  par  le  ministre  de  la  Defense  nationale, 

*  2003 

*  Written  by  Jason  McKenna,  summer  2003  for  DRDC 
*/ 


/*  simHPortScan.cc 

Simulates  a  horizontal  port  scan  from  one  host  vs  a  range  of  hosts. 
Specified  IP  will  scan  another  specified  IPs  for  open  UDP  port, 
usage : 

simHPortScan  <file>  <sourceIP>  <startDestIP>  <endDestIP>  <port>  <speed>  [ — r ] 
*/ 

#include  "teplib.h"  //use  the  TCPLib  to  write  PCap  files. 

#include  <iostream.h> 

#include  <stdlib.h> 

#include  <sys/time.h> 
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#include  <time.h> 

#include  <unistd.h> 

#define  TTL  111  //default  TTL  if  none  specified  on  cmd  line 
#define  PACKETLEN  54 

#define  TIME_STAMP_START  1055936617  //  About  7:45,  June  18,  2003 

#define  RAND_DELTA  0x7fffffff  //used  to  flag  that  you  want  random  generated 

#define  IP_ID_INIT  25338 

#define  IP_ID_DELTA  256  //256  is  typical  for  Win  machines,  1  or  random  typical 

//for  *nix  —  set  to  RAND_DELTA  if  you  want  a  random  ip  id  delta 

#define  IPJTOS  0x10 

#define  IP_DONT_FRAG  true 

#define  IP_MORE_FRAG  false 

#define  UDP_SRC_PORT_INIT  3605 

#define  UDP_SRC_PORT_DELTA  RAND_DELTA  //set  to  RAND_DELTA  for  random  src  port 

#define  POS_FILE  1 

#define  POS_SOURCE  2 

#define  POS_STARTIP  3 

#define  POS_ENDIP  4 

#define  POS_PORT  5 

#define  POS_SPEED  6 

#define  POS_RANDOM  7 

void  displayHelp ( ) ; 

int  main(int  argc,  char  **  argv)  { 
struct  timeval  tm; 
gettimeofday (Stm, NULL) ; 
srand(getpidl) ) ; 
srand(tm.tv_usec) ; 

uint8_t  smac[6]  =  {0x00,  0x08,  0xe3,  0x17,  OxdO,  0x90  };  //source  mac 
//  for  packets  (hardware  addr  of  router) 

uint8_t  dmac[6]  =  {0x00,  OxeO,  Oxle,  0xa5,  0x14,  0xe2  };  //dest  mac  for 
//  packets  (harware  addr  of  firewall  or  server,  depending 
//  on  how  firewall  is  configured) 

//did  user  ask  for  help 

for  (int  i  =  1;  i  <  argc;  i++)  { 

if  (strcmp (argv[i] ,  "-h")  ==  0  I  strcmp (argv [i] , " — help")  ==  0)  { 
displayHelp () ; 
return  0; 

} 

} 

//did  user  enter  incorrect  args 
if  ((argc  !=  7)  &&  (argc  !=  8))  { 

displayHelp () ; 
return  1; 

} 

//read  IPs  from  cmd  line 

uint32_t  sourcelP  =  strTolP (argv [POS_SOURCE] ) ; 
uint32_t  startDestIP  =  strTolP (argv [POS_STARTIP] ) ; 
uint32_t  endDestIP  =  strTolP (argv [POS_ENDIP] ) ; 

if (ntohs (startDestIP)  >  ntohs (endDestIP) )  { 
uint32_t  temp  =  startDestIP; 
startDestIP  =  endDestIP; 
endDestIP  =  temp; 

) 


//fill  a  "destIP"  array  with  port  numbers 

uint32_t  destIP [ntohl (endDestIP)  -  ntohl (startDestIP)  +  1J; 
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for  (int  i  =  ntohl (startDestIP) ;  i  <=  ntohl (endDestIP) ;  i++)  { 
destIP [i-ntohl (startDestIP) ]  =  htonl(i); 

} 

//get  the  port 

int  port  =  atoi (argv [POS_PORT] ) ; 

//if  the  user  specif ed  an  extra  arg  on  cmd  line... 
if  (argc  ==  8)  { 

//if  arg  was  "-r",  randomize  order  of  ports 
if  (strcmp (argv [POS_RANDOM] ,  "-r" )  ==  0)  { 

for  (int  i  =  0;  i  <=  ntohl (endDestIP)  -  ntohl (startDestIP) ;  i++)  { 
int  swapPos  =  rand()  %  (ntohl (endDestIP)  -  ntohl (startDestIP) ) ; 
uint32_t  temp  =  destIP [i]; 
destIP  [i]  =  destIP [swapPos] ; 
destIP [swapPos]  =  temp; 

} 

//otherwise,  display  help 
}  else  { 
displayHelp () ; 
return  1; 

} 

} 


//read  the  speed  from  the  command  line 
float  f speed  =  atof (argv [POS_SPEED] ) ; 
if  (fspeed  ==  0.0)  { 

//if  user  entered  invalid  speed  (0  or  non-numeric); 
displayHelp () ; 
return  1; 

} 

if  (fspeed  <  0)  fspeed  =  -fspeed; 
int  delays  =  (int)  (1 . 0/f speed) ; 

int  delayu  =  (int)  (1000000.0  /  (fspeed  -  ((float)  delays))); 

//seed  the  randomizer 
srand (time (NULL) ) ; 

//create  the  file  header  to  be  used  in  the  output  file 

struct  pcap_file_header  fh; 

fh. magic  =  TCPDUMP_MAGIC; 

f h . p  c  ap_ve  r  s i o n_ma  j  o  r =P  C AP_VE  RS I ON_MA JOR ; 

fh.pcap_version_minor=PCAP_VERSION_MINOR; 

fh.thiszone  =  0; 

fh.sigfigs  =  0; 

fh.snaplen  =  68; 

fh.linktype  =  1;  //ethernet 


TcplibFileWriter  *  writer  =  new  TcplibFileWriter (argv[POS_FILE] ,  fh) ; 

TcplibUDPPacket  *  p  =  new  TcplibUDPPacket (PACKETLEN) ; 
struct  timeval  timestamp; 
gettimeofday (Stimestamp,  NULL); 
timestamp. tv_sec  =  TIME_STAMP_START; 

//set  ethernet  header  info  (protocol  set  by  ip  constructor) 
p->setEthernetSourceMAC (smac) ; 
p->setEthernetDestMAC (dmac) ; 

//ip  ver,  ihl,  tos,  tot_len,  flags,  frag_offset,  protocol  set  by 
//  constructor 
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p->setIPSourceAddress (sourcelP) ; 

//p->setIPDestAddress (destIP)  ; 
p->setIPTTL (TTL)  ; 

p->setIPDontFragBit ( IP_DONT_FRAG) ; 
p->setIPMoreFragBit (IP_MORE_FRAG) ; 
p->setIPTypeOfService (IP_TOS) ; 
int  id  =  IP_ID_INIT; 
int  sPort  =  UDP_SRC_PORT_INIT; 

if  (UDP_SRC_PORT_DELTA  ==  RAND_DELTA)  sPort  =  rand()  %  65536; 

//for  each  ip  in  out  list... 

for  (int  i  =  0;  i  <=  (ntohl (endDestIP)  -  ntohl (startDestIP) ) ;  i++)  { 

p->setTimestamp (timestamp) ; 

p->setIPDestAddress (destIP [i] ) ; 

p->setUDPDestPort (port) ; 

p->setUDPSourcePort (sPort) ; 

p->setIPID (id) ; 

p->setIPChecksum(p->calculateIPChecksum() ) ; 

//int  sum  =  p->calculateUDPChecksum() ; 
p->setUDPChecksum(p->calculateUDPChecksum() ) ; 
writer->writePacket (p) ; 

//for  debug  purposes 

//cout  <<  "Wrote  packet  "  <<  i  «  endl; 

//get  packet  readey  for  next  write; 

//get  next  timestamp 
timestamp. tv_sec  +=  delays; 
timestamp.tv_usec  +=  delayu; 
if  (timestamp. tv_usec  >=  1000000)  { 
timestamp.tv_usec  -=  1000000; 
timestamp. tv_sec++; 

} 

//select  new  source  port 
if  (UDP_SRC_PORT_DELTA  ==  RAND_DELTA)  { 
sPort  =  rand()  %  65536; 

}  else  { 

//increment,  and  loop  if  appropiate 
sPort  +=  UDP_SRC_PORT_DELTA; 
if  (sPort  >=  65536)  { 
sPort  -=  65536; 

} 

} 

//select  new  tcp  seqence  # 

/*if  (TCP_SEQ_DELTA  ==  RAND_DELTA)  { 
seq  =  rand  () ; 

}  else  { 

//increment,  and  loop  if  appropiate 
seq  +=  TCP_SEQ_DELTA; 

}*/ 

//select  new  ip  id 
if  (IP_ID_DELTA  ==  RAND_DELTA)  { 
id  =  rand()  %  65536; 

}  else  { 

//increment,  and  loop  if  appropiate 
id  +=  IP_ID_DELTA; 
if  (id  >=  65536)  { 
id  -=  65536; 

} 

} 
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delete  p; 
delete  writer; 

cout  «  "Successful.”  «  endl; 
return  0; 

} 

void  displayHelp ()  { 

cout  «  "simHPortScan :  Generates  a  horizontal  UDP  scan  vs  a  host  range"  «  endl  <<  endl 

«  "usage:  simPortScan  <file>  <sourceIP>  <startDestIP>  <endDestIP>  <port>  <speed>  [-r] "  <<  endl  <<  endl 
«  "  file:  name  of  file  to  output."  <<  endl 

«  "  sourcelP/startDestIP/endDestIP :  IP  addresses  of  attacker/targets"  <<  endl 
«  "  port:  Port  to  scan"  «  endl 
«  "  speed:  Scan  speed  in  packets/second"  <<  endl 
«  "  -r:  (optional)  randomize  scan  order"  <<  endl  <<  endl 

«  "Compiled  with  TCPLib  "  «  TCPLIB_VERSION_MAJOR  «  "."  «  TCPLIB_VERSION_MINOR  «  «  TCPLIB_VERSION_EXTRA  « 

} 

B.3  Smurf  DoS  Generators 

B.3.1  simSmurfl.cc 

/*  Copyright 

*  (C)  Her  Majesty  the  Queen,  as  represented  by  the  Minister  of  National  Defence, 

*  2003 

*  (C)  Sa  majeste  la  reine,  representee  par  le  ministre  de  la  Defense  nationale, 

*  2003 

*  Written  by  Jason  McKenna,  summer  2003  for  DRDC 
*/ 


/*  Used  to  simulate  incomming  packets  to  launch  a  Smurf  attack  vs  another 

*  machine. 

*  usage:  simSmurfl  <outfile> 

*/ 

#include  "tcplib.h" 

#include  <sys/time.h> 

#include  <stdlib.h> 

//This  is  used  to  define  the  length  of  the  text  of  the  echo  message 
#define  ECHO_MSG_LEN  190 

//The  IP  was  choosen  randomly  from  Dec  2002  traffic 
//  210.103.139.129  translates  to  (net  byte  order)  0xd2678b81 
#define  SOURCEIP  0xd2678b81 

//This  MAC  was  associated  with  the  address  above  from  the  2002  traffic. 

//  This  is  just  the  MAC  of  the  next  link  in  the  chain  connecting  to  the  host 
#define  SOURCEMAC  {  0x00,  0x08,  0xe3,  0x17,  OxdO,  0x90  } 

//  Modified  to  obsificate  DREnet  IPs 
#define  DESTIP  0xACA8ffff 
//  MAC  of  the  router 

#define  DESTMAC  {  0x00,  0x30,  0x80,  Oxce,  Oxba,  0xa2  } 

int  main(int  argc,  char  **  argv)  { 
if  (argc  !=  2)  { 

cout  «  "Error:  you  must  specify  one  (1)  output  file."  <<  endl; 


44 


DRDC  Ottawa  TM  2004-242 


return  1; 

}  else  { 

//Generate  file  header 

} 

//create  pcap  file  header 
pcap_f ile_header  fh; 

fh. magic  =  TCPDUMP_MAGIC;  //tcpdump  magic  number 
fh .pcap_version_ma jor  =  2;  //major  pcap  version 
fh .pcap_version_minor  =  4;  //minor  pcap  version 
fh.thiszone  =  fh.sigfigs  =  0; 

fh.snaplen  =  68;  //default  68  byte  capture  length 
fh.linktype  =  1;  //ethernet 

//this  is  what  we'll  be  using  to  write  to  the  file 
TcplibFileWriter  *  writer  =  new  TcplibFileWriter (argv[l] ,  fh) ; 

//create  the  packet  header 
pcap_packet_header  ph; 

struct  timeval  timestamp; 
gettimeofday (&timestamp,  NULL); 

ph.ts  =  timestamp; 

ph.caplen  =  fh.snaplen;  //caplen  <=  snaplen 

ph.len  =  ETHER_HDR_LEN  +  sizeof (iphdr)  +  sizeof (icmphdr)  +  ECHO_MSG_LEN; 

TcpliblCMPPacket  *  p  =  new  TcpliblCMPPacket (fh. snaplen) ; 
p->setRawHeader (ph) ; 

//generate  ethernet  header 

//generate  random  MACs 

uint8_t  smac [ETHER_ADDR_LEN]  =  SOURCEMAC; 

uint8_t  dmac [ETHER_ADDR_LEN]  =  DESTMAC; 

//set  MACs  &  protocol  type 
p->setEthernetSourceMAC (smac) ; 
p->setEthernetDestMAC (dmac) ; 

//set  up  the  IP  header 
p->setIPVersion (IPVERSION) ; 
p->setIPHeaderLength (5) ; 

p->setIPSourceAddress (ntohl (SOURCEIP) ) ;  //make  the  apparent  target  of  the  smurf 
p->setIPDestAddress (ntohl (DESTIP) ) ;  //send  packet  to  broadcast  address 
p->setIPPacketLength (sizeof (iphdr)  +  sizeof (icmphdr)  +  ECHO_MSG_LEN) ; 
p->setIPTTL  (242) ;  //TTL  initially  set  to  255  in  original  smurf. c 
p->setIPDontFragBit (true) ;  //should  be  the  only  IP  flag  set 
p->setIPChecksum (p->calculateIPChecksum ( ) ) ; 
p->setICMPType (ICMP_ECHO)  ; 

writer->writePacket (p) ; 
delete  p; 
delete  writer; 
return  0; 

} 


B.3.2  simSmurf  2a .  cc 

/*  Used  to  simulate  incomming  packets  to  launch  a  Smurf  attack  vs  another 

*  machine. 

*  usage:  simSmurf 2a  <outfile>  <numpackets>  [-r]  <ip>  <trigger  file>  <delay> 
*/ 
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#include  "tcplib.h" 

#include  <sys/time.h> 

#include  <stdlib.h> 

//This  is  used  to  define  the  length  of  the  text  of  the  echo  message 
#define  ECHO_MSG_LEN  190 

//The  IP  was  choosen  randomly  from  Dec  2002  traffic 
//  210.103.139.129  translates  to  (net  byte  order)  0xd2678b81 
#define  SOURCEIP  0xd2678b81 

//This  MAC  was  associated  with  the  address  above  from  the  2002  traffic. 

//  This  is  just  the  MAC  of  the  next  link  in  the  chain  connecting  to  the  host 
#define  SOURCEMAC  {  0x00,  0x08,  0xe3,  0x17,  OxdO,  0x90  } 

//  Modified  to  obsificate  DREnet  IPs 
#define  DESTIP  0xACA8ffff 
//  MAC  of  the  router 

#define  DESTMAC  {  0x00,  0x30,  0x80,  Oxce,  Oxba,  0xa2  } 

#define  POS_FILE  1 
#define  POS_NUM_PACKETS  2 
#define  POS_DELAY  3 
#define  POS_REPLY  4 
#define  POS_IP  5 
#define  POS_TRIGGER  6 
#define  POS_INIT_DELAY  7 

void  displayHelp () ; 

int  main(int  argc,  char  **  argv)  { 

//check  to  see  if  user  requested  help 
for  (int  i  =  1;  i  <  argc;  i++)  { 

if  ( (strcmp (argv [i] ,  "-h")  ==  0)  | | (strcmp (argv [i] ,  " — help”)  ==  0))  { 
displayHelp () ; 
return  0; 

} 

} 

if  ((argc  !=  4)  &&  (argc  !=  8))  { 
displayHelp () ; 
return  1; 

}  else  { 

uint32_t  sourceip; 
bool  replyMode  =  false; 

int  numPackets  =  atoi (argv [POS_NUM_PACKETS] ) ; 
int  delay  =  atoi (argv [POS_DELAY] ) ; 
if  ((numPackets  ==  0)  ||  (delay  ==  0))  { 
displayHelp () ; 
return  1; 

}  else  { 

struct  timeval  timestamp; 
int  initialDelay  =  0; 
if  (argc  ==  8)  { 
replyMode  =  true; 

initialDelay  =  atoi (argv [POS_INIT_DELAY] ) ; 

TcplibFileReader  *  trigger  =  new  TcplibFileReader (argv [POS_TRIGGER] ) ; 

timestamp  =  trigger->getNextPacket () ->getTimestamp () ; 

timestamp . tv_usec  +=  (initialDelay); 

if  (timestamp. tv_usec  >=  1000000)  { 

timestamp . tv_sec++ ; 

timestamp.tv_usec  -=  1000000; 

} 

sourceip  =  strToIP (argv [POS_IP] ) ; 
delete  trigger; 
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}  else  { 

gettimeofday (Stimestamp,  NULL); 

} 

//create  pcap  file  header 
pcap_f ile_header  fh; 

fh. magic  =  TCPDUMP_MAGIC;  //tcpdump  magic  number 
fh .pcap_version_ma jor  =  2;  //major  pcap  version 
fh .pcap_version_minor  =  4;  //minor  pcap  version 
fh.thiszone  =  fh.sigfigs  =  0; 

fh.snaplen  =  68;  //default  68  byte  capture  length 
fh.linktype  =  1;  //ethernet 

//this  is  what  we'll  be  using  to  write  to  the  file 

TcplibFileWriter  *  writer  =  new  TcplibFileWriter (argv[POS_FILE] ,  fh) ; 

//create  the  packet  header 
pcap_packet_header  ph; 


ph.ts  =  timestamp; 

ph.caplen  =  fh.snaplen;  //caplen  <=  snaplen 

ph.len  =  ETHER_HDR_LEN  +  sizeof (iphdr)  +  sizeof (icmphdr)  +  ECHO_MSG_LEN; 

TcpliblCMPPacket  *  p  =  new  TcpliblCMPPacket (fh. snaplen) ; 
p->setRawHeader (ph) ; 

//generate  ethernet  header 

uint8_t  smac [ETHER_ADDR_LEN]  =  SOURCEMAC; 

uint8_t  dmac [ETHER_ADDR_LEN]  =  DESTMAC; 


//set  up  the  IP  header 
p->setIPVersion (IPVERSION) ; 
p->setIPHeaderLength (5) ; 
if  (IreplyMode)  { 

cout  «  "Entering  non-reply  mode."  <<  endl; 

p->setIPSourceAddress (ntohl (SOURCEIP) ) ;  //make  the  apparent  target  of  the  smurf 
p->setIPDestAddress (ntohl (DESTIP) ) ;  //send  packet  to  broadcast  address 
p->setIPTTL  (242) ;  //TTL  initially  set  to  255  in  original  smurf. c 
p->setICMPType (ICMP_ECHO) ; 
p->setEthernetSourceMAC (smac) ; 
p->setEthernetDestMAC (dmac) ; 

}  else  { 

cout  «  "Entering  reply  mode."  «  endl; 
p->setIPSourceAddress (sourceip) ; 
p->setIPDestAddress (ntohl (SOURCEIP) )  ; 

p->setIPTTL  (254) ;  //TTL  initially  set  to  255  in  original  smurf. c 
p->setICMPType (ICMP_ECHOREPLY) ; 
p->setEthernetSourceMAC (dmac) ; 
p->setEthernetDestMAC (smac) ; 

} 

p->setIPPacketLength (sizeof (iphdr)  +  sizeof (icmphdr)  +  ECHO_MSG_LEN) ; 

p->setIPDontFragBit (true) ;  //should  be  the  only  IP  flag  set 

p->setIPChecksum(p->calculateIPChecksum() ) ; 

for  (int  i  =  0;  i  <  numPackets;  i++)  { 

writer->writePacket (p) ; 

timestamp. tv_usec  +=  (delay); 

if  (timestamp. tv_usec  >=  1000000)  { 

timestamp . tv_sec++ ; 

timestamp.tv_usec  -=  1000000; 

} 

p->setTimestamp (timestamp) ; 

} 

delete  p; 
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delete  writer; 
return  0; 

} 

} 

} 


void  displayHelp ()  { 

cout  «  "simSmurf2a : "  <<  endl  «  endl 


«  "Generates  a  trace  as  if  an  attacker  was  sending  several  packets  to  us,  in  an"  «  endl 
«  "  attempt  to  flood  the  target  (spoofed  source  ip).  Our  fw  blocks  ICMP."  <<  endl  <<  endl 


} 


«  "usage: 

«  " 

«  " 

«  " 

«  " 

«  " 


simSmurf2a  <outfile>  cnumber  of  packets>  <time  between  packets  (us)>"  «  endl 
[-r  <ip>  <trigger  file>  <delay>]"  <<  endl  «  endl 

where  the  presence  of  -r  indicates  to  generate  echo  replys  instead  of"  «  endl 
echo  requests.  The  <delay>  argument  specified  the  delay  from  the"  <<  endl 
original  timestamp  (the  first  packet  in  the  <trigger  file>)  to  generate"  <<  endl 
the  reponses.  <ip>  is  the  IP  responding."  «  endl; 


B.3.3  simSmurf  2b .  cc 

/*  Reply  to  smurf  packets  incomming. 

*  usage:  simSmurf 2b  ctrigger  file>  <outfile>  <host>  <min  delay>  <max  delay> 

*  trigger  file  is  the  file  containing  the 
*/ 

#include  "tcplib.h" 

#include  <sys/time.h> 

#include  <stdlib.h> 

#define  POS_FILE  2 
#define  POS_MINDELAY  4 
#define  POS_MAXDELAY  5 
#define  POS_IP  3 
#define  POS_TRIGGER  1 

//make  code  cleaner  by  shortenting  cast 
#define  ip(p)  ( (TcpliblPPacket  *)p) 

void  displayHelp () ; 

int  main(int  argc,  char  **  argv)  { 

//check  to  see  if  user  requested  help 
for  (int  i  =  1;  i  <  argc;  i++)  { 

if  ( (strcmp (argv [i] ,  "-h")  ==  0)  | | (strcmp (argv [i] ,  " — help")  ==  0))  { 
displayHelp () ; 
return  0; 

} 

} 

if  (argc  !=  6)  { 
displayHelp () ; 
return  1; 

}  else  { 

uint32_t  sourceip; 

int  mindelay  =  atoi (argv [POS_MINDELAY] ) ; 

int  delayvar  =  atoi (argv [POS_MAXDELAY] )  -  mindelay; 

int  delay; 

sourceip  =  strToIP (argv [POS_IP] ) ; 
if  ((delayvar  ==  0)  I  I  (mindelay  ==0) )  { 
displayHelp () ; 
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return  1; 

}  else  { 

struct  timeval  timestamp; 
gettimeofday (stimestamp,  NULL); 
s rand (timestamp. tv_u sec) ; 

TcplibFileReader  *  trigger  =  new  TcplibFileReader (argv [POS_TRIGGER] ) ; 

TcplibFileWriter  *  writer  =  new  TcplibFileWriter (argv[POS_FILE] ,  trigger->getFileHeader ( ) ) ; 

TcplibPacket  *  p; 

while  ( ! trigger->eof ( ) )  { 

p  =  trigger->getNextPacket () ; 

if  (p->isICMPPacket () )  { 

if  ( ( (TcpliblCMPPacket  *)p) ->getICMPType ()  ==  ICMP_ECHO)  { 
ip (p) ->setIPDestAddress (ip (p) ->getIPSourceAddress () ) ; 
ip (p) ->setIPSourceAddress (sourceip) ; 

( (TcpliblCMPPacket  *) p) ->setICMPType (ICMP_ECHOREPLY) ; 

ip (p) ->setIPChecksum (ip (p) ->calculateIPChecksum ( ) ) ; 

timestamp  =  p->getTimestamp () ; 

delay  =  mindelay  +  (rand()  %  delayvar) ; 

timestamp.tv_usec  +=  (delay); 

while  (timestamp. tv_usec  >=  1000000)  { 

timestamp. tv_sec++; 

timestamp.tv_usec  -=  1000000; 

} 

p->setTimestamp (timestamp) ; 
ip (p) ->setIPTTL (64) ; 

( (TcpliblCMPPacket  *)p) ->setICMPChecksum ( ( (TcpliblCMPPacket  *)p) ->calculateICMPChecksum() ) ; 
ip (p) ->setIPChecksum (ip (p) ->calculateIPChecksum ( ) ) ; 
writer->writePacket  (p) ; 

} 

} 

delete  p; 

} 

delete  writer; 
return  0; 

} 

} 

} 

void  displayHelp ()  { 

cout  «  "simSmurf2b : "  <<  endl  «  endl 

«  "  usage:  simSmurf2b  <trigger  file>  <outfile>  <host>  <min  delay>  <max  delay>"  «  endl; 

} 


B.3.4  simSmurf2.pl 

# ! /usr/bin/perl 

#  Jason  McKenna,  winter  2004 

#  Perl  script  for  simulating  that  a  network  was  the  target  to  a  smurf  attack. 

#  This  script  makes  used  of  the  simSmurf2  program  ,  built  on  TCPLib. 

#  modified  11  Feb  2004  JT 

#  modified  15  Feb  2004  JM 

#  tcpjitter  args 

$ jittersource  =  "dl  t30";  # jitter  on  incomming  packets 

$jittereach  =  "d0.5";  #drop  0.5%  of  reply  packets  (due  to  large  net  traffic 
$jitterfinal  =  "t20" ;  # jitter  timestamps  20%  AFTER  merging. 

#hash  of  attackers 

#  each  hash  represents  the  suffix  of  the  IP  for  the  host  responding,  and  the 
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#  min  delay  for  response.  Max  delay  is  (2) (min  delay) 
%att  =  ( 

"1"  =>  141, 

"2"  =>  131, 

"3"  =>  134, 

"8"  =>  342, 


10" 

=  > 

112, 

11" 

=  > 

105, 

12" 

=  > 

98, 

13" 

=  > 

93, 

14" 

=  > 

105, 

15" 

=  > 

107, 

20" 

=  > 

214, 

2i" 

=  > 

250, 

23" 

=  > 

204, 

24" 

=  > 

199, 

25" 

=  > 

201, 

26" 

=  > 

157, 

28" 

=  > 

293, 

29" 

=  > 

261, 

30" 

=  > 

220, 

31" 

=  > 

278, 

33" 

=  > 

134, 

45" 

=  > 

203, 

46" 

=  > 

210, 

47" 

=  > 

221, 

48" 

=  > 

205, 

49" 

=  > 

213, 

53" 

=  > 

167, 

66" 

=  > 

183, 

71" 

=  > 

203, 

72" 

=  > 

223, 

73" 

=  > 

101, 

80" 

=  > 

302, 

81" 

=  > 

289, 

82" 

=  > 

319, 

83" 

=  > 

401, 

88" 

=  > 

134, 

CTi 

CO 

=  > 

154, 

112' 

= 

>  222, 

113' 

= 

>  230, 

121' 

= 

>  223, 

132' 

= 

>  303, 

144' 

= 

>  132, 

145' 

= 

>  128, 

146' 

= 

>  191, 

149' 

= 

>  178, 

151' 

= 

>  164, 

152' 

= 

>  129, 

153' 

= 

>  107, 

155' 

= 

>  184, 

182' 

= 

>  223, 

192' 

= 

>  334, 

193' 

= 

>  245, 

194' 

= 

>  267, 

203' 

= 

>  112, 

205' 

= 

>  343, 

232' 

= 

>  349, 

237' 

= 

>  393, 

244' 

= 

>  159, 

245' 

= 

>  161, 

251' 

= 

>  402) 

♦create  trigger  file 
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system (" . /simSmurf2a  smurf 2partl-orig. tcp  10000  100000"); 

system ("tcp jitter  smurf2partl-orig. tcp  smurf2partl . tcp  $ jittersource" ) ; 

system ("rm  smurf 2Partl-orig. tcp") ; 

$files  =  "smurf2partl .tcp"; 

$ournet  =  "172.168.199."; 

foreach  $host (keys (%att) )  { 

print  ("IP  $host  delaying  for  "  .  $att{$host}  ."  us\n"); 

system  " . /simSmurf2b  smurf2partl . tcp  smurf2part$ournet$host"  .  "a. tcp  $ournet$host  $att{$host}  "  .  (2  * 
#print  " . /simSmurf2b  smurf2partl . tcp  smurf2part$host"  .  "a. tcp  $host  $att{$host}  "  .  (2  *  $att{$host}) 
system ("tcp jitter  smurf2part$ournet$host"  .  "a. tcp  smurf2part$ournet$host\ .tcp  $ jittereach" ) ; 
system("rm  smurf2part$ournet$host"  .  "a. tcp"); 

$files  =  $files  .  "  smurf2part$ournet$host\ .tcp"; 

} 

print  "Merging. .. \n"; 

$mergecmd  =  "tcpmerge  $files  smurf 2. tcp"; 
print  "$mergecmd  \n"; 
system  "$mergecmd"; 

print  "Cleaning  up...\n"; 

print  "rm  $files\n"; 
system  ("rm  $files"); 

print  "Done\n"; 


B.3.5  simSmurf3b.  cc 

/*  Copyright 

*  (C)  Her  Majesty  the  Queen,  as  represented  by  the  Minister  of  National  Defence, 

*  2003 

*  (C)  Sa  majeste  la  reine,  representee  par  le  ministre  de  la  Defense  nationale, 

*  2003 

*  Written  by  Jason  McKenna,  summer  2003  for  DRDC 
*/ 


/*  simSmurf3b . cc 

*  This  will  attempt  to  simulate  part  of  a  smurf  attack.  Imagine  the  situation 

*  where  a  network  has  been  pinged  to  the  broadcast  address.  Each  computer  in 

*  on  the  network  will  respond  to  the  ping.  Now  if  the  source  address  in  the 

*  original  IP  header  had  been  spoofed,  then  the  victim  (the  machine  with  the 

*  spoofed  address)  is  flooded.  This  program  will  simulate  the  response  from 

*  a  single  host  on  the  network  which  has  been  pinged.  It  will  read  in  the 

*  timestamps  from  the  specified  tcpdump  input  file  (the  packets  do  not  need  to 

*  be  ICMP  echo  requests,  all  we  are  using  them  for  is  a  timestamp) ,  delay  the 

*  specified  number  of  microseconds,  and  send  a  response  based  around  the  packet 

*  format  from  the  original  smurf. c. 

*/ 

#include  "tcplib.h" 

//This  is  used  to  define  the  length  of  the  text  of  the  echo  message 
#define  ECHO_MSG_LEN  190 

//This  MAC  was  associated  with  the  address  above  from  the  2002  traffic. 

//  This  is  just  the  MAC  of  the  next  link  in  the  chain  connecting  to  the  host 
#define  SOURCEMAC  {  0x00,  0x08,  0xe3,  0x17,  OxdO,  0x90  } 

//  MAC  of  the  router 

#define  DESTMAC  {  0x00,  0x30,  0x80,  Oxce,  Oxba,  0xa2  } 


$att {$host} ) 

.  "\n"; 
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#define  OS_WIN  0 
#define  OS_LINUX  1 

//marker  used  to  specify  that  a  field  should  be  randomized 
#define  RAND  -65536 

//Describe  how  Windows  machines  reply  to  pings 
#define  WIN_IP_ID_INIT  RAND 
#define  WIN_IP_ID_DELTA  256 

#define  WIN_TTL  122  //initially  set  to  128,  but  there  are  some  hops 

//descrive  how  'nix  reply  to  pings 
#define  LINUX_IP_ID_INIT  RAND 
#define  LINUX_IP_ID_DELTA  1 
#define  LINUX_TTL  249  //initiall  set  to  255 

#define  POS_INFILE  1 
#define  POS_OUTFILE  2 
#define  POS_SOURCEIP  3 
#define  POS_TARGETIP  4 
#define  POS_DELAY  5 
#define  POS_OS  6 

void  displayHelp () ; 

int  main(int  argc,  char  **argv)  { 
for  (int  i  =  1;  i  <  argc;  i++)  { 

if  ( (strcmp (argv [i] ,  ”-h")  ==  0)  ||  (strcmp (argv [i] ,  " — help”)  ==  0))  { 
displayHelp () ; 
return  0; 

} 

} 

if  ((argc  !=  6)  &&  (argc  !=  7))  { 
displayHelp () ; 
return  1; 

}  else  { 

//open  the  file  for  reading 

TcplibFileReader  *  reader  =  new  TcplibFileReader (argv[POS_INFILE] ) ; 
//Generate  output  file  header 
pcap_file_header  fh; 

fh. magic  =  TCPDUMP_MAGIC;  //tcpdump  magic  number 
fh.pcap_version_ma jor  =  2;  //major  pcap  version 
fh.pcap_version_minor  =  4;  //minor  pcap  version 
fh.thiszone  =  fh.sigfigs  =  0; 

fh.snaplen  =  68;  //default  68  byte  capture  length 
fh.linktype  =  1;  //ethernet 

//this  is  what  we'll  be  using  to  write  to  the  file 

TcplibFileWriter  *  writer  =  new  TcplibFileWriter (argv[POS_OUTFILE] ,  fh) ; 

TcpliblCMPPacket  *  p  =  new  TcpliblCMPPacket (fh. snaplen) ; 

//modify  the  packet  header 
pcap_packet_header  ph  =  p->getRawHeader () ; 

ph.len  =  ETHER_HDR_LEN  +  sizeof (iphdr)  +  sizeof (icmphdr)  +  ECHO_MSG_LEN; 
p->setRawHeader (ph) ; 

p->setIPPacketLength (sizeof (iphdr)  +  sizeof (icmphdr)  +  ECHO_MSG_LEN) ; 

int  delay  =  atoi (argv [POS_DELAY] ) ; 

//generate  ethernet  header 

//generate  random  MACs 

uint8_t  smac [ETHER_ADDR_LEN]  =  SOURCEMAC; 

uint8_t  dmac [ETHER_ADDR_LEN]  =  DESTMAC; 

//set  MACs  &  protocol  type 
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p->setEthernetSourceMAC (smac) ; 
p->setEthernetDestMAC (dmac) ; 

//set  up  the  IP  header 
p->setIPVersion (IPVERSION)  ; 
p->setIPHeaderLength (5) ; 

p->setIPSourceAddress (strToIP (argv [POS_SOURCEIP] ) ) ;  //make  the  apparent  target  of  the  smurf 

p->setIPDestAddress (strToIP (argv [POS_TARGETIP] ) ) ;  //send  packet  to  broadcast  address 
int  os; 

if  (argc  ==  7)  { 

if  (strcmp (argv [POS_OS] , "-w" )  ==  0)  { 
os  =  OS_WIN; 

}  else  if  (strcmp (argv [POS_OS] ,  "-1")  ==  0)  { 
os  =  OS_LINUX; 

}  else  { 
displayHelp () ; 
return  1; 

} 

}  else  { 
os  =  OS_WIN; 

} 

int  ttl; 

int  ipid; 

int  iddelta; 

switch  (os)  { 

case  OS_WIN : 

ttl  =  WIN_TTL; 

ipid  =  WIN_IP_ID_INIT; 

iddelta  =  WIN_IP_ID_DELTA; 

break; 

case  OS_LINUX : 

ttl  =  LINUX_TTL; 

ipid  =  L I NUX_I P_I D_I N I T ; 

iddelta  =  LINUX_IP_ID_DELTA; 

break; 

default : 

cout  «  "ERROR:  This  message  should  never  appear."  <<  endl; 
return  1; 

} 

if  (ipid  ==  RAND)  { 
ipid  =  rand()  %  65536; 

} 

p->setIPDontFragBit (true) ;  //this  should  be  the  only  IP  flag  set 
p->setICMPType (ICMP_ECHOREPLY)  ; 

TcplibPacket  *  pt; 
struct  timeval  ts; 
while  ( ! reader->eof () )  { 
if  (ttl  ==  RAND)  { 
p->setIPTTL (rand ()  %  256); 

}  else  { 

p->setIPTTL (ttl) ; 

} 

pt  =  reader->getNextPacket () ; 
ts  =  pt->getTimestamp () ; 
ts.tv_usec  +=  delay; 
if  (ts.tv_usec  >  1000000)  { 
ts.tv_sec  +=  (ts.tv_usec  /  1000000); 
ts.tv_usec  %=  1000000; 

} 

p->setIPID (ipid) ; 
p->setTimestamp (ts) ; 
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delete  pt; 

p->setIPChecksum (p->calculateIPChecksum ( ) ) ; 
p->setICMPChecksum(p->calculateICMPChecksum() ) ; 
writer->writePacket  (p) ; 
if  (iddelta  ==  RAND)  { 
ipid  +=  (rand()  %  65536); 

}  else  { 

ipid  +=  iddelta; 

}; 

ipid  %=  65536; 

} 

delete  reader; 
delete  p; 
delete  writer; 
return  0; 

} 

} 


void  displayHelp ()  { 

cout  «  "simSmurf3b  help"  <<  endl  <<  endl 

«  "  Simulates  the  response  from  one  computer  on  a  network  to  a  spoofed  source  IP."  <<  endl 

«  "  Used  in  conjunction  with  simSmurf3a.pl  to  simulate  entire  smurf  attack."  «  endl  <<  endl 

«  "  usage:  simSmurf3b  <input  timestamp  file>  <output  file>  <source  IP>  <target  IP>  <delay>  [os]"  <<  endl  «  endl 

«  "  <input  timestamp  file>  -  TCPDump  file  containing  packets  with  timestamps  to  treat  as  pings"  <<  endl 
«  "  coutput  file>  -  Name  of  file  to  write  to."  <<  endl 

«  "  <source  IP>  -  IP  address  of  computer  sending  ping  responses"  <<  endl 

«  "  <target  IP>  -  IP  of  computer  being  smurfed"  «  endl 

«  "  <delay>  -  Delay  of  packets  due  to  network  noise  (us) "  <<  endl 

«  "  [os]  -  (optional)  OS  to  mimic  (-w  =  Windows,  -1  =  GNU/Linux) "  <<  endl  <<  endl; 

} 

B.3.6  simSmurf3a.pl 

# !  /usr/bin/perl 

#  Perl  script  for  simulating  that  a  network  was  the  target  to  a  smurf  attack. 

#  This  script  makes  used  of  the  simSmurf3b  program,  built  with  TCPLib. 

#  In  order  to  simulate  a  number  of  hosts  responding  to  a  particular  PING 

#  request,  we  create  a  file  which  has  a  number  of  packets.  This  file  is  used 

#  to  synchronise  the  responses,  leading  to  this  impression  that  all  hosts  are 

#  responding  to  the  same  packet. 

#constants  (make  these  command  line  options  in  next  version?) 

$target  =  "172.168.244.255"; 

$attackerPref ix  =  "61.182.0.";  #netscan.org  reports  that  this  subnet  responds  w/ 

#69  responses  to  a  ping  at  61.182.0.255,  but  I  didn't  actually  send  a 
#ping  so  the  unique  IPs  and  OSs  below  are  just  hypotheticals 

$delay  =  240; 


#ugly  but  it  works  (note  to  self  —  use  a  hash  next  time) 


Oattackers  = 

(1  , 

"1",  2 

,  "w" 

3  , 

"w", 

4  ,"1 

,  8 

,  "1" 

9  ," 

w",  10 

,  "1 

",  11 

,  "w" 

, 

12  , 

"w",  13  , 

’w", 

17  ,  "w" 

,  18 

,  "1" 

,  20 

,  "w" , 

21 

"w" , 

22  ," 

w",  23 

,  "1 

",  24 

,  "1" 

, 

25  , 

"w",  27  , 

’w", 

28  ,  "w" 

,  29 

,  "w" 

,  31 

,  "w" , 

32 

"1", 

33  ," 

1",  35 

,  "w 

",  38 

,  "w" 

, 

128 

,  "1",  129 

,  "w' 

,  130  , 

"w" , 

131 

,  "w" 

132 

"  ]_ " 

134 

,  "  w  " , 

135  , 

1"/ 

152  , 

"w" , 

158 

"1 

159 

,  "w",  162 

,  "1' 

,  163  , 

"1", 

164 

,  "1" 

165 

"w" 

166 

,  "1", 

167  , 

w"  , 

172  , 

"w" , 

173 

"w 

174 

,  "w",  175 

,  "1' 

,  176  , 

"w" , 

177 

,  "w" 

178 

"w" 

179 

,  "1", 

180  , 

w" , 

181  , 

"w" , 

182 

"w 

188 

sf 

CO 

>x> 

,  "w' 

,  192  , 

"w" , 

204 

,  "w" 

220 

"w" 

221 

,  "  w  "  , 

222  , 

’w", 

238  , 

"1", 

242 

"w 
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#rate  of  packets  (per  second,  10  is  a  good  number) 

$rate  =  10; 

#amount  of  time  to  simulate  trace  for  (seconds) 

#  max  is  (2~16  -  2  (=65534?) ) /$rate 

#  another  way  of  looking  at  this  is  "how  many  pings  to  broadcast  address" 

$simtime  =  3000;  #  if  #rate  =  10,  this  is  300s  or  5  mins 

#max  amount  to  shift  trace  by  (us) 

$maxshift  =  500;  #  =  0.5ms 

#tcpjitter  args 

$jitter  =  "t20  dl";  #jitter  time  by  up  to  20%,  drop  1%  of  packets 

#name  of  timer  file  (will  be  deleted,  so  be  sure  it's  original 
$timerfile  =  "timer.tcp"; 

#command  to  generate  timer  file 

$gentimer  =  " . /simPortScan  $timerfile  1.1. 1.1  2. 2. 2. 2  1  $simtime  $rate"; 

#ok,  now  we  do  stuff 

print  "Generating  timer  file...\n"; 

system  "$gentimer"; 

print  "\nCreateing  traces ... \n"; 

$mergecmd  =  "tcpmerge"; 

$n  =  0; 

foreach  $host  (Oattackers)  { 
if  ($host  ne  "1"  &&  $host  ne  "w")  { 

print  "From  host  $attackerPref ix$host . . .  simulating. .. \n"; 

$cmd  =  " . /simSmurf 3b  $timerfile  smurf3 . $host .tcp  $attackerPrefix$host  $target  $delay  -"; 
$cmd  =  $cmd  .  Oattackers [$n  +  1]; 

$n  =  $n  +  2; 

system  "$cmd"; 

$r  =rand ($maxshift ) ; 

$r  =~  / \ . / ; 

$r  =  $ '  +  1; 

print  "Making  more  realistic. .. \n"; 

system  "tcptimeshift  smurf 3 . $host .tcp  smurf3.$host .a. tcp  0  $r"; 
system  "tcpjitter  smurf3 . $host .a. tcp  smurf3 . $host . tcp  $jitter"; 

$mergecmd  =  $mergecmd  .  "  smurf 3 . $host . tcp"; 
print  "Cleaning  temp  files ... \n"; 
system  "rm  smurf3.$host .a. tcp"; 

} 

} 

print  "Merging. .. \n"; 

$mergecmd  =  $mergecmd  .  "  smurf 3. tcp"; 
system  "$mergecmd"; 

print  "Cleaning  up...\n"; 
foreach  $host (Oattackers)  { 
if  ($host  ne  "1"  &&  $host  ne  "w")  { 
system  "rm  smurf 3 . $host . tcp" ; 

} 

} 

system  "rm  $timerfile"; 
print  "Done\n"; 
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B.4  TFN2K  DoS  Generator 

B.4.1  even.pl 


# ! /usr/bin/perl 

#  tfnx  are  tfn2k-syn-x  timeshifted  to  same  timespace 

#apply  TTL  modifiers: 

#  client  1:  5  hops 

#  client  2:  12  hops 

#  client  3:  17  hops 

#  client  4:  8  hops 

#  client  5:  20  hops 

system  "tcpttltranslate  tfnl.tcp  tfnl-2.tcp  -5"; 
system  "tcpttltranslate  tfn2.tcp  tfn2-2.tcp  -12"; 
system  "tcpttltranslate  tfn3.tcp  tfn3-2.tcp  -17"; 
system  "tcpttltranslate  tfn4.tcp  tfn4-2.tcp  -8"; 
system  "tcpttltranslate  tfn5.tcp  tfn5-2.tcp  -20"; 

#merge  tfns  and  stretch  them  out  to  just  above  5Mbps 

system  "tcpmerge  tfnl-2.tcp  tfn2-2.tcp  tfn3-2.tcp  tfn4-2.tcp  tfn5-2.tcp  tfn_a.tcp"; 
system  "rm  tfnl-2.tcp  tfn2-2.tcp  tfn3-2.tcp  tfn4-2.tcp  tfn5-2.tcp"; 
system  "tcptimestretch  tfn_a.tcp  tfn_b.tcp  5.7"; 
system  "rm  tfn_a.tcp"; 

#extract  heart  of  DDoS  (remove  any  delay  from  starts) 
system  "tcpslice  -w  tfn_c.tcp  +2  +107  tfn_b.tcp"; 
system  "rm  tfn_b.tcp"; 

#make  trace  68  byte  packet  cap  len 
system  "tcptrunc  tfn_c.tcp  tfn_d.tcp  68"; 
system  "rm  tfn_c.tcp"; 

#clean  traffic  is  divided  into  parti. tcp  part2.tcp  and  part3.tcp.  part2  is 

#  length  of  tfn_d.tcp 

#align  in  time  and  merge  two  traces  for  part  2 

system  "tcptimeshift  tfn_d.tcp  tfn_e.tcp  -109569783  -854176"; 

system  "rm  tfn_d.tcp"; 

system  "tcpmerge  part2.tcp  tfn_e.tcp  part2a.tcp"; 


for  ($i  =  0;  $i  <  106;  $i++)  { 

#extract  the  current  second  from  the  file 

system  "tcpslice  -w  part2_$i.tcp  +$i  +1  part2a.tcp"; 

system  "tcpslice  -w  ddos2_$i.tcp  +$i  +1  tfn_e.tcp"; 

system  "tcpslice  -w  clean_$i.tcp  +$i  +1  part2.tcp"; 

#find  the  rate  in  the  current  second 

system  "tcprate  part2_$i.tcp  >  temp.txt"; 

open  FH,  "temp.txt"; 

$f  =  <FH>; 

$f  =~  /\s/; 

$rate  =  $' ; 

$f  =  <FH>; 

$f  =~  /\s/; 

$rate  +=  $' ; 
print  "$rate\n"; 
if  ($rate  >  579570)  { 

$float  =  ($rate  -  579570) /$rate  *  100; 
print  "Dropping  $float  %\n"; 

system  "tcp jitter  ddos2_$i.tcp  ddos3_$i.tcp  d$float"; 
system  "tcpjitter  clean_$i.tcp  clean3_$i . tcp  d$float"; 
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}  else  { 

system  "cp  ddos2_$i.tcp  ddos3_$i .tcp"; 
system  "cp  clean_$i.tcp  clean3_$i.tcp"; 

} 

$mergeclean  =  $mergeclean  .  "  clean3_$i . tcp"; 

$mergeddos  =  $mergeddos  .  "  ddos3_$i . tcp" ; 
system  "rm  part2_$i.tcp  ddos2_$i.tcp  clean_$i.tcp"; 
close  FH; 

} 

system  "rm  part2a.tcp  tfn_e.tcp"; 

print  "tcpmerge  $mergeclean  part2_clean. tcp\n"; 
system  "tcpmerge  $mergeclean  part2_clean.tcp"; 
print  "tcpmerge  $mergeddos  part2_ddos . tcp\n"; 
system  "tcpmerge  $mergeddos  part2_ddos . tcp"; 

print  "tcpmerge  part2_ddos . tcp  part2_clean.tcp  part2_mix.tcp\n"; 
system  "tcpmerge  part2_ddos . tcp  part2_clean.tcp  part2_mix.tcp" ; 

system  "rm  $mergeclean  $mergeddos  temp.txt"; 
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Annex  C 

List  of  Acronyms 


ACK/RST/SYN/FIN 

ASCII 

DDoS 

DEFCON 

DoS 

DREnet 

DRDC 

ICMP 

IDS 

IP 

IP  ID 

NetBIOS 

OS 

TCP 

TTL 

UDP 

VA 


TCP  header  flags 

American  Standard  Code  for  Information  Interchange 
Distributed  Denial  of  Service 
DEFense  CONdition 
Denial  of  Service 

Defence  Research  Establishment  network 
Defence  Research  and  Development  Canada 
Internet  Control  Message  Protocol 
Intrusion  Detection  System 
Internet  Protocol 

Internet  Protocol  IDentification  header  field 

Network  Basic  Input/Output  System 

Operating  System 

Transmission  Control  Protocol 

Time  To  Live 

User  Datagram  Protocol 

Vulnerability  Assessment 
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